Comment 6 for bug 1169164

Hi Ian, sorry I was preempted, I'll post the patch here as soon as possible.

On 26 March 2014 18:37, Ian Campbell <email address hidden> wrote:
> Any pointers to the proposed fix? I'm happy to test with it.
>
> --
> You received this bug notification because you are a member of Linaro
> Toolchain Developers, which is subscribed to Linaro GCC.
> https://bugs.launchpad.net/bugs/1169164
>
> Title:
> including signal.h exposes various PSR_MODE #defines
>
> Status in Linaro GCC:
> New
> Status in Linaro AArch64 cross-distro work:
> Triaged
>
> Bug description:
> I have a userspace application (part of the Xen userspace) which
> #includes <signal.h>. On arm64this causes preprocessor symbols such as
> PSR_MODE_EL0t to become defined and these clash with the applications
> own use of those names (via its inclusion of the Xen public headers):
>
> tools/include/xen/arch-arm.h:229:0: error: "PSR_MODE_EL0t" redefined [-Werror]
> In file included from \
> /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/sys/use \
> r.h:25:0,
> from \
> /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/sys/pro \
> cfs.h:34,
> from \
> /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/sys/uco \
> ntext.h:26,
> from \
> /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/signal. \
> h:360, from xentrace.c:21:
> /usr/lib/gcc-cross/aarch64-linux-gnu/4.7/../../../../aarch64-linux-gnu/include/asm/ptr \
> ace.h:30:0: note: this is the location of the previous definition
>
> I am running Raring in a chroot using Wookey's aarch64 multiarch
> bootstrap repos. The details of how I setup my chroots are at
> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompiling.
>
> Interesting packages:
> libc 2.17-0ubuntu4profile1
> binutils-aarch64-linux-gnu 2.23.1-0ubuntu11cross0.4
> gcc-aarch64-linux-gnu 4:4.7.2-1
>
> Xen is, FWIW, the latest http://xenbits.xen.org/gitweb/?p=xen.git
> staging branch.
>
> I initially fixed thi swith the kernel patch seen at
> http://marc.info/?l=linux-arm-kernel&m=136577951814167&w=2 but the
> conclusion seems to be that it is OK for uapi/ptrace.h (or indeed
> <ptrace.h>) to define whatever it wants so the issue is that including
> <signal.h> in userspace eventually leads to including ptrace.h.
> signal.h is POSIX so is restricted in what namespace it is permitted
> to claim.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gcc-linaro/+bug/1169164/+subscriptions