Dear Dirk,
In message 4A59F95A.6060803@googlemail.com you wrote:
I really hesitate to do that. It seems that not using the compiler provided library is not such a clever thing to do. The compile writes probably know better what a specific version of GCC needs that anybody else.
Yes, you are basically right. But ;)
But, as Jean-Christophe mentioned above, it's a pain with the various ARM tool chains floating around. Some are older, some are newer, some are configured for EABI, some not, some are configured for software floating point, some for hardware floating point, etc., etc.
Right. And each of these is supposed to come with it's own version of libgcc, configured exactly for the requirements of this specific version and configuration of GCC.
And it turns out that the majority of architectures works just fine with such a setup, just using libgcc for functions required for and provided by the compiler.
If the compiler provided functions cannot be used, this is IMO an indication of a broken toolchain, which should either be fixed (if it's under some form of maintenance) or abandoned (because you will have the same problems again in other situations outside of U-Boot).
While I as developer might be able to find a recent tool chain with a libgcc compatible with U-Boot, I think we should avoid this pain for our users. Users which like to "just compile U-Boot" and then we tell them "well, your tool chain you seem to be happy with doesn't link U-Boot, for U-Boot you have to install an other one" I think wouldn't make them happy.
From the technical point of view it is only reasonable to point out
that these users have a broken toolchain, and that they should take the first opportunity to fix or replace it.
Of course it it nice if we can also provide a workaround for them, so they can update at a point in time that is convenient to them. But the implementation of such a workaround should be clean, and eventually be used only for systems that really need it.
In no case we should make the use of such a workaround for broken setups the rule which has to be used by all systems (and eventually all architectures, even those that never had such problems in the first place).
This is why I really hesitate to apply these patches - they make the workaround for a few broken systems the rule, instead of making clear that this is an exception needed only by some (broken) systems.
Regarding not using the compilers library and if this clever: No, it isn't clever, you are right again. The compiler's library version is most probably better optimized. But, we are dealing with a boot loader
This is in no way a question of optimization. If we provide replacements for the libgcc functions, _we_ will have to maintain these and make sure they work correctly with all versions of GCC that exist in the multiverse and with all of their possible and impossible configurations. That's a lot of work we put on ouw own back for - for what?
here. So for the topic we discuss here, I think avoiding some pain for us ("my tool chain doesn't compile U-Boot, help!" mails at this list) and our users (see above) is the stronger argument than some optimization/performance issues in some (seldom?) used math functions.
I think that answering a few mails, pointing out known problems with broken tool chains requires by far less amount of effort than adding this code. Heck, discussing and testing of this patch took already way more of my time than replying to all related messages in the last 3 years together...
I think the patch needs to be changed such that it needs to be specifically enabled for broken tool chains, and that by default all systems behave the same, i. e. assume a working tool chain and use libgcc.
Best regards,
Wolfgang Denk