[Buildroot] Trouble with buildroot for ARM EABI

[Buildroot] Trouble with buildroot for ARM EABI

[Daniel Mack]

Hi,

we've been hunting down weird effects regarding a build for ARM EABI  
with the 20090113 br2 snapshot.

As far as we tracked things down, at least one of the culprits is the  
uClibc package which does not generate bits/sysnum.h correctly. The  
file include/unistd.h that ships with the kernel defines the syscall  
numbers depending on __ARM_EABI__, which is not set correctly by  
uclibc when it is included to generate sysnum.h. Hence, the generated  
file (eventually in build_arm/staging_dir/usr/include/bits/sysnum.h)  
contains false assumptions about the offset of syscalls as it sets it  
to 0x900000 which is only valid for OABI. The effect of this  
misbehaviour are instantly crashing target binaries, at least when  
OABI compat support is switched off in the kernel config.

We tried that on different Debian/unstable boxed which all show equal  
effects. I really wonder why nobody else stumbled over this issue  
before. Could anyone shed some light on and propose a fix for this  
issue?

Thanks,
Daniel

[Buildroot] Trouble with buildroot for ARM EABI

[Daniel Mack]

Hi,

On Sat, Jan 17, 2009 at 01:26:42AM +0100, Daniel Mack wrote:
> we've been hunting down weird effects regarding a build for ARM EABI  
> with the 20090113 br2 snapshot.
> 
> As far as we tracked things down, at least one of the culprits is the  
> uClibc package which does not generate bits/sysnum.h correctly. The  
> file include/unistd.h that ships with the kernel defines the syscall  
> numbers depending on __ARM_EABI__, which is not set correctly by  
> uclibc when it is included to generate sysnum.h. Hence, the generated  
> file (eventually in build_arm/staging_dir/usr/include/bits/sysnum.h)  
> contains false assumptions about the offset of syscalls as it sets it  
> to 0x900000 which is only valid for OABI. The effect of this  
> misbehaviour are instantly crashing target binaries, at least when  
> OABI compat support is switched off in the kernel config.

Here is a patch that corrects this behaviour (sent as patch creating a
patch, so I can inline it here). I'll also send this upstream to uclibc
as soon as the bugtracker server is back from his weekend break.

But anyway, there needs to be a fix for buildroot as well, as I'd say
uclibc-0.9.30 ships in a broken state.

Comments on this?

Best regards,
Daniel


--- /dev/null	2009-01-13 12:00:33.996423014 +0100
+++ toolchain/uClibc/uClibc-0.9.30-gen-bits-syscall-eabi.patch	2009-01-17 20:51:35.000000000 +0100
@@ -0,0 +1,12 @@
+--- ./extra/scripts/gen_bits_syscall_h.sh.orig	2009-01-17 20:42:02.000000000 +0100
++++ ./extra/scripts/gen_bits_syscall_h.sh	2009-01-17 20:48:27.000000000 +0100
+@@ -22,6 +22,9 @@
+ *)     CC_SYSNUM_ARGS="-dN" ;;
+ esac
+ 
++grep -q "^CONFIG_ARM_EABI=y" .config && \
++	INCLUDE_OPTS="${INCLUDE_OPTS} -D__ARM_EABI__"
++
+ ( echo "#include <asm/unistd.h>";
+   echo "#include <asm/unistd.h>" |
+   $CC -E $CC_SYSNUM_ARGS $INCLUDE_OPTS - |

[Buildroot] Trouble with buildroot for ARM EABI

[Sven Neumann]

Hi,

On Sat, 2009-01-17 at 01:26 +0100, Daniel Mack wrote:

> As far as we tracked things down, at least one of the culprits is the  
> uClibc package which does not generate bits/sysnum.h correctly. The  
> file include/unistd.h that ships with the kernel defines the syscall  
> numbers depending on __ARM_EABI__, which is not set correctly by  
> uclibc when it is included to generate sysnum.h. Hence, the generated  
> file (eventually in build_arm/staging_dir/usr/include/bits/sysnum.h)  
> contains false assumptions about the offset of syscalls as it sets it  
> to 0x900000 which is only valid for OABI. The effect of this  
> misbehaviour are instantly crashing target binaries, at least when  
> OABI compat support is switched off in the kernel config.

__ARM_EABI__ is a define built into gcc. So the proper fix is to make
sure that gcc is built for the correct target. It seems that it is
possible to create a buildroot configuration where this is not the case.

We have now configured our build for ARM with iwmmxt. After I manually
change the gcc target suffix to 'linux-uclibcgnueabi' everything started
to work out correctly. Perhaps the buildroot config system should try
harder to make sure that this is correctly set.

The relevant parts of our working .config are:

 BR2_GCC_TARGET_TUNE="iwmmxt"
 BR2_GCC_TARGET_ARCH="iwmmxt"
 BR2_GCC_TARGET_ABI="iwmmxt"
 BR2_TARGET_ARM=y
 BR2_GNU_TARGET_SUFFIX="linux-uclibcgnueabi"

Unfortunately strace does not compile with this setup. But that's a
different probelem...


Sven