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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
