including signal.h exposes various PSR_MODE #defines

Bug #1169164 reported by Ian Campbell
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linaro AArch64 cross-distro work
Fix Committed
Medium
Riku Voipio
Linaro GCC
Fix Released
Undecided
Yvan Roux

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.

Revision history for this message
Riku Voipio (riku-voipio) wrote :

Looking at differences between x86_64 and aarch64 versions of signal.h, both include sys/ucontext.h, where only the aarch64 version includes <sys/procfs.h> which in turn says:

/* Anyway, the whole purpose of this file is for GDB and GDB only.
     Don't read too much into it. Don't use it for anything other than
     GDB unless you know what you are doing. */

Doesn't seem like including it from a posix header like <signal.h> is safe.

Changed in linaro-aarch64:
status: New → Triaged
Revision history for this message
Yvan Roux (yvan-roux) wrote :

It seems that <sys/procfs.h> is include to provide the elf_gregset_t and elf_fpregset_t types, thus I think the fix is to define the regset types in sys/ucontext.h as it is done on the other targets.

Changed in linaro-aarch64:
importance: Undecided → Low
Fathi Boudra (fboudra)
Changed in linaro-aarch64:
importance: Low → Medium
Fathi Boudra (fboudra)
Changed in gcc-linaro:
assignee: nobody → Ryan S. Arnold (ryan-arnold)
Changed in linaro-aarch64:
assignee: nobody → Riku Voipio (riku-voipio)
Revision history for this message
Ryan S. Arnold (ryan-arnold) wrote :

Yvan has a proposed fix for this. Once he gets it to me I need to run it on Aarch64 to verify.

Revision history for this message
Ian Campbell (ijc) wrote :

Any pointers to the proposed fix? I'm happy to test with it.

Revision history for this message
Yvan Roux (yvan-roux) wrote : Re: [Bug 1169164] Re: including signal.h exposes various PSR_MODE #defines

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

Revision history for this message
Yvan Roux (yvan-roux) wrote :

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

Fathi Boudra (fboudra)
Changed in gcc-linaro:
assignee: Ryan S. Arnold (ryan-arnold) → Yvan Roux (yvan-roux)
Revision history for this message
Ian Campbell (ijc) wrote :

Hi, I was just wondering if there was any progress on this issue?

Revision history for this message
Yvan Roux (yvan-roux) wrote :

Hi Ian,

I discussed the patch with maintainer and it's still not approved, but here it is if you want to test it.

Revision history for this message
Ian Campbell (ijc) wrote :

Thanks Yvan. I applied these changes to /usr/include on an opensuse 13.1 system chroot and the Xen tools built successfully without my usual hack, thanks!

Where can I follow the discussion with the glibc maintainer? I looked at linaro-toolchain and the libc-alpha list and didn't see it.

Revision history for this message
Yvan Roux (yvan-roux) wrote :

Ok cool :)

It wasn't on any mailing list, just an IRC chat, but I'll bring it to the glibc mailing list as soon as glibc will be test with this patch. I'll put a link here to the patch submission thread when available.

Changed in gcc-linaro:
status: New → In Progress
Revision history for this message
Yvan Roux (yvan-roux) wrote :
Revision history for this message
Yvan Roux (yvan-roux) wrote :
Changed in gcc-linaro:
status: In Progress → Fix Committed
Changed in linaro-aarch64:
status: Triaged → Fix Committed
Changed in gcc-linaro:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.