Re: "struct user" conflicts on arm
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.
Reply to: