[Buildroot] ARM EABI builds

[Ben Dooks <ben@fluff.org>]

On Fri, Jun 29, 2007 at 01:01:31AM +0200, Bernhard Fischer wrote:
> On Thu, Jun 28, 2007 at 03:54:22PM -0400, Stuart Wood wrote:
> >Just a note on what Tom said about user land application. I've already 
> 
> Just as a note on what everybody seems to say about configuring GCC:
> It is very amusing that you guys seem to be excited about _not_ setting
> a config option -- CONFIG_BR2_EXTRA_TARGET_GCC_CONFIG_OPTIONS -- which
> is specifically exported to you, to spell out specific requirements put
> upon gcc (other toolchain parts of course also provide said means for
> hand-crafted  options, mind you).

The point I was making in bug 1406, is that the config system already
asks you which cpu you are building for, and then does not pass it to
programs that use it, such as the compiler configuration. 
 
> >found that I had to add -march=armv4t to properly build my application, Just
> 
> doh!
> 
> >because gcc was not using the right load register code for the data 

you'll have also seen that libgcc.a has various optimisations in routines
such as the division/modulus helpers which use instructions like CLZ,
which only got added in ARMv5.

> well, if you don't tell it to do and _do not help in improving the
> generic situation_ how should we guess what you are trying to achieve?
> 
> Get real. (yes, i'm in a bad mood and i'm fond of stupid whining about
> 'Doctor, it hurts when i..'
> 
> Q:
> Dear X-mas whatever. I want this and that. Now. Immediately. No, i have
> no idea how to implement 'this' 'now', but it has to be done. What? Nah,
> no idea what 'this' nor 'that' nor 'now' is supposed to do, i'd have
> provided a guidance otherwise.
> A: alright. At your service.
> 
> >size I wanted to read. It would use ldrw instead of ldrh. So, It would 
> >help avoid those errors.
> 
> Try searching the archives for CPU selection (from memory, so may not be
> accurate) for further details.
> >
> >Stuart
> 
> See below.
> >
> >Tom wrote:
> >> 
> >> 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 
> 
> bug #1406 is completely crap. Let me cite:
> <quote>
>  Reporter  	 bjdooks
>  Summary  	 0001403: printf and anything using vfprintf() hangs

that's not bug 1406, looks like 1403 to me.

>  system
>  Description 	Any function using vfprintf, such as printf and snprintf
>  cause the system to stop. A test program shows that stdout is
>  functional, as fwrite() to stdout will display messages on the console
>  Additional Information 	uclibc 0.9.29
>  gcc 4.1.2 (arm-linux-uclibcgnueabi)
>  binutils 2.17.50.0.16
>  configure for ARM920T, EABI
> ---
> (0002514)
> bjdooks
> 06-25-07 17:26
> 
> 	The bug is still present in the development snapshot 
> ---
> (0002517)
> bjdooks
> 06-26-07 05:03
> 
> 	Building gcc 4.1.2 for OABI (patches will be sent in seperate
> 	report) does not work either.
> </quote>
> >toolchain to build their own code w/o always setting these options)
> 
> - No actual error shown.

I thought vfprintf() hangs is a pretty good error report, the system
did not give me any more information, and when you can't run init, then
it is very difficult to get gdb to do anything.

> - no code/arch/toolchain hints to reproduce.

I added details of the versions of the toolchain (gcc, uclibc) and the
ARM core being configured for ARM920T. Ok there was no .config attached
which wasn't helpful.

> This is one of the 'Doctor, it hurts'.. goto above;

ok, so not the world's best bug report, but after several days of
frustration with EABI not producing a working build, and OABI simply
not building a compiler, I was getting frustrated.

I finally got some inspiration from elsewhere, and decided to
disassemble libgcc.a and found the culprits in the div/mod code
and then set about trying to correct these.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.