[Buildroot] ARM EABI builds

[Tom]

Ben Dooks wrote:
>> We need to keep in mind that the same gcc toolchain can support several 
>> subarchitectures, thus this naming would be somewhat misleading (for 
>> example, in our cases it did produce both ARMv4 (in the kernel) and 
>> ARMv5 (in user libs)).
> 
> Yes, the naming would indicate the default cpu the compiler is configured
> for. The gcc docs[1] indicate the --with-cpu= option only sets the
> default cpu to compile for. Unfortunately this affects how it produces
> libgcc.
> 
> I don't see why you would end up producing ARMv4 kernel when producing
> an ARMv5 user space. Either you are producing a kernel to run on the 
> same arch as your userspace (the kernel will correctly assign -mcpu=<x>)
> when it is building.
>  
Why? Because of the bug: Configured all builds with ARM920T:
Buildroot creates "incorrect" toolchain, "incorrect" toolchain fails to 
build uclibc in ARMv4 only  but uses ARMv5. However, it did build a 
kernel in ARMv4 fine.


>> To me it would be great if the gcc toolchain always printed out whatever 
>> the default SUBTARGET / CPU is as part of its specs. (It does this only 
>> if one is passed with the --with-cpu option, so if it's not passed, you 
>> can't easily find the default.) This would have helped me immensely to 
>> find the --with-cpu workaround, but I am afraid this is not really a 
>> buildroot issue.
> 
> It is part of a problem with gcc where libgcc is being built for some
> arbitrary default, instead of one suitable for each architecture that
> can be selected at run-time.
> 
> The problem with buildroot is that it gives you a choice of ARM cpus.
> If you select ARM920T, then you have an expectation of being able
> to run the binaries produced on an ARM920T, which currently if EABI
> is also selected is impossible.

Yes, I agree. I like your solution in 
http://busybox.net/bugs/view.php?id=1406 .

> 
> I did think about adding -mcpu=<cpu> to the build CFLAGS, but that
> is not going to help with the problem that libgcc is not going to
> be compiled correctly.
> 
Why not? The kernel image, built with the same "incorrect" toolchain, 
must have used only ARMv4 instructions. If it hadn't, I would have never 
gotten far enough to even execute vprintf, libc. I would suspect that 
the kernel does a better job of setting -mcpu, -mtune. Thus these 
options should work for libc too. What makes you think that it wouldn't 
work for libc, have you tried? (PS: Even if it did, bug #1406 is 
probably the better fix, in particular as buildroot users might use its 
toolchain to build their own code w/o always setting these options)