On arm linux sys/ucontext.h heavilly polloutes the global namespace firstly by including sys/user.h (which defines among other things a type called "struct user" and secondly by defining symbols and #defines named R? to represent the processor registers.
That issue in itself is nothing new but fairly recently* signal.h started including sys/ucontext.h by default causing programs that (quite reasonable IMO) used those names for their own symbols to fail to build on arm. This has been especially noticable recently because debian is trying to build the new "armhf" port.
After discussions on debian-arm/debian-glibc/linaro-dev (I do not know which responders came from which list) I was given the following advice on the "struct user" issue by Ulrich Weigand.
Now, glibc also provides a file <sys/ucontext.h> that defines layouts of register sets for use with signal handlers as well as the makecontext/setcontext/getcontext family of routines.
Usually, those layouts tend to be in fact identical to the layouts described in <sys/user.h> / <sys/procfs.h>. Apparently, whoever implemented the ARM version of <sys/ucontext.h> was trying to avoid some seemingly unnecessary code duplication by making <sys/ucontext.h> *include* <sys/procfs.h> and using the information from there directly. This is not done on other platforms, for precisely the reason that the <sys/procfs.h> and <sys/user.h> headers do pollute the name space ...
So I think the right thing to do in the short term would be to stop <sys/ucontext.h> including <sys/procfs.h>, and instead add the register set information there directly, even if that means some duplication of code. (Again, since this is never-changing ABI, duplication isn't actually all that bad. Also, all the other platforms do it that way too, so why should ARM be different ...)
On the issue of the R? definitions I proposed renaming them to REG_R?. The use of a REG_ prefix is consistent with x86, x64 and sparc (I couldn't find any comparable definitions at all on other architectures I looked at) I asked what the impact of this change would be on the aforementioned mailing lists and got the following reply from Konstantinos Margaritis
at worst the packages that had to be workaround on arm* for this, can have the workaround removed.
The attached patch implements these changes.
My tests do not show any new failures in the libc testsuite (though I do get failures that debian considers "unexpected" regardless of whether this patch is applied or not)
* I have not investigated exactly when this change occoured but it was somewhere between the version in debian squeeze and the version in debian wheezy.
On Mon, 19 Dec 2011, peter green wrote:
On the issue of the R? definitions I proposed renaming them to REG_R?. The use of a REG_ prefix is consistent with x86, x64 and sparc (I couldn't find any comparable definitions at all on other architectures I looked at) I asked what the impact of this change would be on the aforementioned mailing lists and got the following reply from Konstantinos Margaritis
at worst the packages that had to be workaround on arm* for this, can have the workaround removed.
The most obvious users of these definitions would be (native) GDB and gdbserver - do those still build OK (i.e. include the correct headers to get the definitions they need and not rely on any definitions that were removed) after this patch?
Have you verified that it still works to include both <sys/ucontext.h> and <sys/procfs.h> in the same source file, in either order?
Joseph S. Myers wrote:
The most obvious users of these definitions would be (native) GDB and gdbserver - do those still build OK (i.e. include the correct headers to get the definitions they need and not rely on any definitions that were removed) after this patch?
I have built the debian gdb package (which builds both gdb and gdbserver) sucessfully on a system with this patch.
Have you verified that it still works to include both <sys/ucontext.h> and <sys/procfs.h> in the same source file, in either order?
I had already tried that in one order, just tried the other order too. Both work fine.
When I copied a structure definition over to remove the dependency I made sure to rename it (following the name used for the equivilent structure on amd64).
On Tue, 20 Dec 2011, peter green wrote:
Joseph S. Myers wrote:
The most obvious users of these definitions would be (native) GDB and gdbserver - do those still build OK (i.e. include the correct headers to get the definitions they need and not rely on any definitions that were removed) after this patch?
I have built the debian gdb package (which builds both gdb and gdbserver) sucessfully on a system with this patch.
Have you verified that it still works to include both <sys/ucontext.h> and <sys/procfs.h> in the same source file, in either order?
I had already tried that in one order, just tried the other order too. Both work fine.
When I copied a structure definition over to remove the dependency I made sure to rename it (following the name used for the equivilent structure on amd64).
Thanks. I've now applied the patch with the following ChangeLog entry.
2011-12-20 Peter Green plugwash@p10link.net
* sysdeps/unix/sysv/linux/arm/sys/ucontext.h: Don't include <sys/procfs.h>. (gregset_t): Define without using elf_gregset_t. (R0): Rename to REG_R0. (R1): Rename to REG_R1. (R2): Rename to REG_R2. (R3): Rename to REG_R3. (R4): Rename to REG_R4. (R5): Rename to REG_R5. (R6): Rename to REG_R6. (R7): Rename to REG_R7. (R8): Rename to REG_R8. (R9): Rename to REG_R9. (R10): Rename to REG_R10. (R11): Rename to REG_R11. (R12): Rename to REG_R12. (R13): Rename to REG_R13. (R14): Rename to REG_R14. (R15): Rename to REG_R15. (struct _libc_fpstate): New. (fpregset_t): Define using struct _libc_fpstate.
This patch could go in because it was largely mechanical and copying code from elsewhere, but if you intend to make further contributions to glibc you should complete an FSF copyright assignment.
-
Joseph S. Myers -
peter green