From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: Thu, 9 Feb 2017 12:25:10 +0000 Subject: Aarch64 kernel with 32bit userspace question In-Reply-To: References: <0057242a-2e16-3b59-1f81-9f4ccf64216d@denx.de> <0747bd41-7a87-6dd6-11bf-58729ad2c3d8@denx.de> Message-ID: <20170209122509.GD27312@n2100.armlinux.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Feb 09, 2017 at 11:24:43AM +0000, Ard Biesheuvel wrote: > On 9 February 2017 at 11:14, Marek Vasut wrote: > > On 02/09/2017 11:51 AM, Ard Biesheuvel wrote: > >> On 9 February 2017 at 10:14, Marek Vasut wrote: > >>> Hi, > >>> > >>> I'm trying multilib userland on aarch64, but I'm running into a problem. > >>> I have a simple test code: > >>> > >>> -->8-- > >>> #include > >>> > >>> int main(void) { > >>> return 0; > >>> } > >>> --8<-- > >>> > >>> If I compile that with aarch64 gcc , it compiles just fine. > >>> > >>> If I compile the same thing with 32bit armv7ahf multilib gcc, the > >>> build fails on "unknown type name '__uint128_t'". This comes from > >>> arch/arm64/include/uapi/asm/sigcontext.h , which has __uint128_t in > >>> struct fpsimd_context {} . The signal.h includes that (through a few > >>> glibc headers) and that's what triggers the failure. __uint128_t is > >>> defined on aarch64 , but it is not on armv7a (32bit). > >>> > >> > >> This is a toolchain or glibc bug: the arm64 version of that header > >> should never be pulled in when using a AArch32 toolchain, regardless > >> of whether you run it on arm64, ARM (or x86, for that matter) > > > > Aha. So which version of the header should be pulled in ? The one from > > arch/arm/include/uapi/asm/sigcontext.h (that doesn't make much sense to > > me) ? > > > > signal.h includes bits/sigcontext.h, of which several versions exists > on my system: > > /usr/aarch64-linux-gnu/include/bits/sigcontext.h > /usr/arm-linux-gnueabi/include/bits/sigcontext.h > /usr/arm-linux-gnueabihf/include/bits/sigcontext.h > /usr/include/x86_64-linux-gnu/bits/sigcontext.h > > each of which includes asm/sigcontext.h under the same root path. > > It is up to the compiler to set the builtin include paths correctly: > arm-linux-gnueabi-gcc should never use the aarch64 or x86 one. The issue may be where arch/arm*/include/uapi/asm/sigcontext.h has been installed to. GCC may be doing the right thing, so selecting the right include directory, but they all include "asm/sigcontext.h". If the ARM64 UAPI headers got dropped into /usr/include/asm, then the compiler may be picking these up rather than the proper ones in the appropriate directory. For me: /usr/include/arm-linux-gnueabihf/bits/sigcontext.h should be picking up on: /usr/include/arm-linux-gnueabihf/asm/sigcontext.h and there should not be a /usr/include/asm directory. The default kernel headers_install will want to place the headers into /asm along side /asm-generic and /linux which is not what modern ARM distros want. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.