Ulrich Weigand>Now, glibc also provides a file <sys/ucontext.h> that defines Ulrich Weigand>layouts of register sets for use with signal handlers as well Ulrich Weigand>as the makecontext/setcontext/getcontext family of routines. Ulrich Weigand> Ulrich Weigand>Usually, those layouts tend to be in fact identical to the Ulrich Weigand>layouts described in <sys/user.h> / <sys/procfs.h>. Apparently, Ulrich Weigand>whoever implemented the ARM version of <sys/ucontext.h> was Ulrich Weigand>trying to avoid some seemingly unnecessary code duplication Ulrich Weigand>by making <sys/ucontext.h> *include* <sys/procfs.h> and using Ulrich Weigand>the information from there directly. This is not done on other Ulrich Weigand>platforms, for precisely the reason that the <sys/procfs.h> Ulrich Weigand>and <sys/user.h> headers do pollute the name space ... Ulrich Weigand> Ulrich Weigand>So I think the right thing to do in the short term would be to Ulrich Weigand>stop <sys/ucontext.h> including <sys/procfs.h>, and instead add the Ulrich Weigand>register set information there directly, even if that means some Ulrich Weigand>duplication of code. (Again, since this is never-changing ABI, Ulrich Weigand>duplication isn't actually all that bad. Also, all the other Ulrich Weigand>platforms do it that way too, so why should ARM be different ...) Makes sense to me

While we are talking about modifying sys/ucontext.h David Given raised another issue with that header (for those reading on the linaro list his post can be found at http://lists.debian.org/debian-arm/2011/12/msg00048.html) David Given>This might be a good time to mention that on ARM, sys/ucontext.h defines David Given>both symbols and preprocessor macros called R0, R1, R2, etc in the David Given>global namespace; this is causing one of my packages to fail to build David Given>due to symbol collision. David Given> David Given>I'm fixing the package, but naming symbols stuff like that is still David Given>pretty antisocial... Does anyone know what the impact of renaming these to use a REG_ prefix like i386, amd64 and sparc do* would be?

* ia64,mips, mipsel, powerpc, 390 and s390x don't seem to define such symbols at all.