This subject came up on debian-arm: http://lists.debian.org/debian-arm/2011/12/msg00025.html
And it seems like the sort of architectural issue linaro should take an interest in fixing to avoid making people's lives difficult when building on arm. Is it on anyone's list already?
In short:
A C app that defines a struct 'user' and uses wait.h or signal.h will find a clash with the system struct of the same name, which should only be needed for GDB (when built on/for arm).
On other arches this is not pulled in by default so the problem doesn't arise.
We can 1) Change every app in the world that defines a 'struct user' 2) Stop these headers getting brought in when not actually needed (it's a relatively recent change that brings it in) 3) Change the name in glibc/GDB to something less likely to clash
disclaimer: I know nothing at all about this except what I just read in that thread. Please refer to the thread for details.
Wookey
Wookey wrote:
We can
- Change every app in the world that defines a 'struct user'
- Stop these headers getting brought in when not actually needed
(it's a relatively recent change that brings it in) 3) Change the name in glibc/GDB to something less likely to clash
Some background from a GDB perspective: the files <sys/procfs.h> and <sys/user.h> define the layout of the various register sets the kernel provides to user space debuggers via ptrace and/or core file register note sections.
In the past, it was considered a good idea for this information to be provided by kernel headers via inclusion into glibc to be used by GDB sources. However, this turned out to not be really feasible with modern GDB: since this information is needed to access core files, and with a cross-debugger we need to access core files produced on some other architecture than the host, we cannot actually rely on system headers (which only provide information about the host architecture). Fortunately, the layout is part of the unchanging kernel ABI, so there is no real need for GDB to rely on any header files in the first place. Therefore, GDB is currently in the process to switching to simply hard-coding register set layouts for various architectures.
Once this process is complete, <sys/user.h> and <sys/procfs.h> will no longer be needed to build GDB. (The process is mostly complete for <sys/user.h>; it will still take a while for <sys/procfs.h>.) However, from a system perspective, it is probably still not a good idea to just remove (or incompatibly change) those headers: you want to keep the capability to compile older GDB sources (and possibly other debuggers).
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 ...)
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
-
Ulrich Weigand -
Wookey