[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file

[Dirk Behme]

Dear Wolfgang,

Wolfgang Denk wrote:
> Dear Dirk,
> 
> In message <4A59F95A.6060803 at 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).

Ah, I understand, most probably we are not aligned about what we talk, 
sorry. Yes, I know, there was some discussion about the Makefiles and 
that there are some requests to change them. Unfortunately, I'm no 
Makefile expert.

So I'm only talking about ARM systems/architecture. If the Makefiles 
discussed previously touch other systems/architectures, too, then this 
is not what I'm talking about.

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

For me the broken systems are in a first step ARM tool chains. Nothing 
more. Not sure if we can limit it to a sub-group of ARM systems, 
though? E.g. would it possible to have a CONFIG_SYS_DONT_RELY_ON_LIBGCC?

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

It was my understanding that Jean-Christophe copied this code from 
kernel? Like we do with some other systems, e.g. MTD? So it's 
maintained by kernel developers? Sorry if I missed something here.

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

Yes. I talk about "broken tool chains == ARM tool chains". Nothing 
more. If the Makefile changes in the patches we talk about do some 
more, then that's not what I mean.

Best regards

Dirk