U-boot linking against libgcc

Related to the discussion we had earlier today about linking to libgcc I have here a experimental patch that removes the linking to libgcc. I called it experimental because I am not able to test if all architectures still compile properly, and as such it needs more (build)testing before integrating. I tested several ARM boards, and they all compile and link fine.

I am convinced that it is the way to go to remove libgcc of the link list, but if we integrate this patch I cannot guarantee it does not break some builds, but it makes clear which boards are depending on interfaces from a library it should not depend on in the first place. Those boards might need additional patches.

I hope you can find some time to do some more compile testing across different architectures.

Kind Regards,

Remy B??hmer

An embedded and charset-unspecified text was scrubbed...
Name: remove-linking-to-libgcc.patch
Url: http://lists.denx.de/pipermail/u-boot/attachments/20081031/08c50acb/attachment.txt

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

Why is it doubtful to remove the only portable way to get variable arguments? stdarg.h should *not* contain OS dependencies.

-Scott

Hello Scott (and Wolfgang),

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.

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

Dear "Remy Bohmer",

raise()? exceptions? In C?

...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 think I saw libgcc on the linker command line ?

If such a thing needs to be done, it is a compiler-issue, and we do not have to know or care about that.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Life is a game. Money is how we keep score.              - Ted Turner

Hello Wolfgang,

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).

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

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.

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

Dear Remy,

I did not say that.

I said if any compiler options must be adapted to match the ABI implemented by the tool chain, then this is an issue that is internal to this tool chain, and nothing we should bother about. If the tool

chain  wants  to  produce  FOO-comptible  code  it  must  make   sure
(internally)  to  set  all  required options and provide all required

library routines for the FOO ABI - whatever that might be.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Never worry about theory as long as  the  machinery  does  what  it's
supposed to do.                                      - R. A. Heinlein

Dear Remy,

And where would the GCC compiler gets its builtin functions from, then?

The toolchain is not OS dependent. It implements a cetrain ABI. And libgcc provides the needed support functions.

I have an idea what you mean, but as stated here it's wrong.

This must never happen. U-Boot is supposed to be self-contained, except for any compiler-speeific functions which are provided by the compiler itself - in libgcc.a (assuming you use GCC).

No, it will not, unless it is misconfigured.

Correct. But we cannot know what the compiler may need or provide.

Huch? I cannot make any sense of this.

Oops? How would you implement support for variable number of arguments then, when you remove the only standard way to do it?

And, do they also run fine?

I think the code would not run (because it uses an incompatible [with the compiler used] ABI version) if you omitted linking against libgcc here.

Different problem, has nothing to do with linking against libgcc per se.

Has nothing to do with libgcc.a

Your patch will break a lot of PPC boards, for example:

Configuring for BC3450 board...
post/libpost.a(post.o): In function `post_time_ms':
/work/wd/u-boot/post/post.c:451: undefined reference to `__udivdi3'
make: *** [u-boot] Error 1

Configuring for cm5200 board...
post/libpost.a(post.o): In function `post_time_ms':
/work/wd/u-boot/post/post.c:451: undefined reference to `__udivdi3'
make: *** [u-boot] Error 1

Configuring for fo300 board...
post/libpost.a(post.o): In function `post_time_ms':
/work/wd/u-boot/post/post.c:451: undefined reference to `__udivdi3'

Configuring for TB5200 board...
post/libpost.a(post.o): In function `post_time_ms':
/work/wd/u-boot/post/post.c:451: undefined reference to `__udivdi3'

Configuring for TQM5200 board...
post/libpost.a(post.o): In function `post_time_ms':
/work/wd/u-boot/post/post.c:451: undefined reference to `__udivdi3'
make: *** [u-boot] Error 1

Configuring for TQM5200_B board... post/libpost.a(post.o): In function `post_time_ms':
/work/wd/u-boot/post/post.c:451: undefined reference to `__udivdi3'
make: *** [u-boot] Error 1

Configuring for TQM5200S board... post/libpost.a(post.o): In function `post_time_ms':
/work/wd/u-boot/post/post.c:451: undefined reference to `__udivdi3'
make: *** [u-boot] Error 1

and so on.

NAK.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Computers make excellent and efficient servants, but I have  no  wish
to  serve under them. Captain, a starship also runs on loyalty to one
man. And nothing can replace it or him.
	-- Spock, "The Ultimate Computer", stardate 4729.4

it will break Blackfin builds as there are a bunch of places where the compiler generates calls to libgcc

i cant see why you'd want to remove libgcc or why you think this is a correct long term goal, but Wolfgang already made a much more detailed list ... -mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20081101/f364f5a2/attachment.pgp