including signal.h exposes various PSR_MODE #defines

Bug #1169164 reported by Ian Campbell on 2013-04-15
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linaro AArch64 cross-distro work
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.

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
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) on 2014-02-03
Changed in linaro-aarch64:
importance: Low → Medium
Fathi Boudra (fboudra) on 2014-02-22
Changed in gcc-linaro:
assignee: nobody → Ryan S. Arnold (ryan-arnold)
Changed in linaro-aarch64:
assignee: nobody → Riku Voipio (riku-voipio)
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.

Ian Campbell (ijc) wrote :

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

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

Yvan Roux (yvan-roux) wrote :

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

Fathi Boudra (fboudra) on 2014-04-02
Changed in gcc-linaro:
assignee: Ryan S. Arnold (ryan-arnold) → Yvan Roux (yvan-roux)
Ian Campbell (ijc) wrote :

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

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.

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.

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
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  Edit
Everyone can see this information.

Other bug subscribers