[U-Boot] [patch 1/1] Remove linking to libgcc while compiling U-boot

[Remy Bohmer]

Hello Scott (and Wolfgang),

> libgcc should *not* be expecting any OS interface.  It may use a few
> basic libc functions such as memcpy, that u-boot provides.

libgcc could also expect the 'raise()' routine to pass divide-by-zero
execeptions. (if __div0, (or __aeabi_ldiv0) is not overruled)
If not overruled, than libgcc can depend on libc, and thus indirectly
depend on a OS interface.

In the mean time things are getting more clear. In the ARM section of
U-boot a large amount of (division) routines which are usually
provided by libgcc are also implemented in the lib_arm directory. For
many ARM boards it is therefore possible to remove linking to libgcc
at all, and it won't hurt the resulting binary at all (because nothing
is currently used from libgcc on ARM).

At first, I thought 'why not remove libgcc if it is not used', but it
is clear to me now that this is not the route to go. I got confused by
the redundant implementation in lib_arm... (Other architectures than
ARM seem to do it better, removing libgcc would break those for the
wrong implementation which is currently in the ARM tree. )

Some routines are still lacking in the lib_arm tree and if GCC starts
generating code (due to some code change) that
requires those missing routines, we now get link errors if a EABI only
compiler is used. (If for example the eabi compiler toolchain of
CodeSourcery is used (e.g. 2008q1) then the provided libgcc is not
compatible with the compile option -mabi=apcs-gnu, the libgcc of the
non-EABI toolchain of CS however seems to be compatible with this
flag)
Today I even saw patches coming by that moves some division routines
to do_div(), just to workaround these linking issues, and thus
actually to prevent linking against libgcc. This happened before in
the past resulting in the (rather big) lib_arm tree.

So, I agree (now) that libgcc should be used, but this is _not the
case_ currently in the ARM tree.

>> While looking at compiler includes, the only header used from GCC (I
>> have seen) seems to be the stdarg.h header, which is even doubtful to
>> include in U-boot, because of the same reasons not to link against
>> libgcc. This patch only removes the linking part to libgcc.
> Why is it doubtful to remove the only portable way to get variable
> arguments?  stdarg.h should *not* contain OS dependencies.

My _first_ conclusion was that the libraries provided by the compiler
toolchain were not suitable to build a standalone application like
U-boot. From that point of view it was logical to say that if no
libraries from a compiler are used, why use any headers?(regardless
what is in there...)

What I now believe that should be done is to investigate (compile
time) what type of ABI is supported by the libgcc provided by the
compiler, and adjust the compile settings to that ABI.
I was already doing some hacks to check if I could get this working...
(A person must have a hobby :-) )
I have removed a lot of redundant implementations in lib_arm and I
have at least succeeded in linking to the EABI libgcc (no hardware
here to test...)

I hope this explanation sounds much more sane to everybody ;-)


Remy