[Buildroot] Bizarre behavior of armeb toolchain

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Thu Jun 20 13:52:36 UTC 2013


On Thu, 20 Jun 2013 15:41:30 +0200, Thomas Petazzoni wrote:

>  (*) On ARMv7 however, the code is different whether -mbig-endian is
>  passed or not, even though an "armeb-linux" compiler is supposed to
>  generate big endian code by default. When no flags is passed, both the
>  data *and* code are big-endian (so it's BE32 like on ARMv5), but
>  passing -mbig-endian makes the thing behave properly (code is
>  little-endian, data is big-endian).

Interestingly, this problem is visible when you run gcc with the -v
option, and look at the options passed to collect2.

when no options are passed to gcc (and it generates incorrect BE32
code), the options passed to collect2 are:

/home/test/outputs/armv7be/host/usr/libexec/gcc/armeb-buildroot-linux-uclibcgnueabi/4.7.3/collect2
	--sysroot=/home/test/outputs/armv7be/host/usr/armeb-buildroot-linux-uclibcgnueabi/sysroot
	--eh-frame-hdr
	-dynamic-linker /lib/ld-uClibc.so.0
	-X -m armelfb_linux_eabi -o toto
	[...]
	/tmp/ccJDVjCg.o

When -mbig-endian is passed to gcc, gcc then passes the following
options to collect2:

/home/test/outputs/armv7be/host/usr/libexec/gcc/armeb-buildroot-linux-uclibcgnueabi/4.7.3/collect2
	--sysroot=/home/test/outputs/armv7be/host/usr/armeb-buildroot-linux-uclibcgnueabi/sysroot
	--eh-frame-hdr
	--be8
	-dynamic-linker /lib/ld-uClibc.so.0
	-X -EB -m armelfb_linux_eabi -o toto
	[...]
	/tmp/ccnje5oi.o

Notice how it passes -EB and more importantly --be8, which indicates to
ld that it should swap code to make it little endian again (after it
has been generated big endian by as).

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com


More information about the buildroot mailing list