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

[Remy Bohmer]

Hello Wolfgang,

>> libgcc could also expect the 'raise()' routine to pass divide-by-zero
>> execeptions. (if __div0, (or __aeabi_ldiv0) is not overruled)
> raise()? exceptions? In C?

Please, do not get pikky about choice of words... You can call it an
exception, signal, or whatever. (If I meant C++-exception handling, I
would call it that way)
According to the docs, overrule __div0 (as done in U-boot) or
implement a raise() routine that does not return, in a OS it is
probably redirected to a signal handler (via libc).

>> 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).
>
> ...unless you use some (probably older) tool chains  where  this  may
> break.  I guess there was a readon to add these functions. We did not
> do this for the fun of it.

I never told it was added for fun...
Even in the case if these functions are added for an old toolchain,
maybe it is preferable to link first to libgcc, and finally to
lib_arm.a to make sure that the most of libgcc functions are used. Or
make it somewhat compiler version related

>> 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
>
>> So, I agree (now) that libgcc should be used, but this is _not the
>> case_ currently in the ARM tree.
> I think I saw libgcc on the linker command line ?

Yep.. it is there on the commandline... but it is useless! No
functions of this lib are used thus libgcc is not used. (on a modern
GCC 4.2.3 toolchain to be precise) On ARM, you can remove it and still
it works...
You can probably link a 100 more libraries, if it won't resolve any
unresolved external, it will not be used.

>> 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.
>
> If such a thing needs to be done, it is a compiler-issue, and we do
> not have to know or care about that.

Okay, now I really lost you, first you have a very strong opinion that
libgcc _must_ be used. I follow you (I admit I was wrong in the
beginning), so I start investigating for a solution to actually start
using libgcc on ARM, and now you tell me you do not want that libgcc
is actually being used on ARM... (Besides, if you are consequent about
the 'not caring' part, you should also not approve the do_div()
patches which are used to get around linking problems with EABI
toolchains..., or any other compiler-bug workarounds...)


Kind Regards,

Remy