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

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

Dear Remy,

In message 20081031224856.847997187@bohmer.net you wrote:

Currently U-boot is linking against libgcc. This should not be needed because

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

the compiler toolchain is usually compiled with a certain OS interface in mind, and can even be configured for GNU-EABI interfaces.

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

This can cause linking conflicts in U-boot when linking to libgcc.

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

It usually becomes really visible that these conflicts are there when some piece of code requires an external routine that is not available in U-boot itself.

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

Such an unresolved external are finally searched in the libgcc library, because U-boot is told to link against. If the compiler happened to be a EABI compiler, linking will definately fail. These are not a compiler problems, but U-boot problems, because

No, it will not, unless it is misconfigured.

U-boot needs to keep its own pants up (It is not linking to any OS, it is standalone)

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

If the compiler is _not_ a EABI compiler toolchain, linking might succeed, but its behaviour will be undefined, because it is unknown what the external dependencies of such libraries will be. (syscalls required?)

Huch? I cannot make any sense of this.

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.

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

I tested it on several ARM boards, and linking still works fine...

And, do they also run fine?

Several older mailthreads that show similar issues (just a simple grep): http://www.mail-archive.com/u-boot-users@lists.sourceforge.net/msg03176.html

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.

http://lists.denx.de/pipermail/u-boot/2008-August/039526.html

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

http://lists.denx.de/pipermail/u-boot/2007-July/022881.html

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