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

[Wolfgang Denk]

Dear Dirk Behme,

In message <4A5A0B5B.2010408 at googlemail.com> you wrote:
> 
> > 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.

Note that this is not a question of ARM versus  other  architectures.
On  ARM  the  use  of  libgcc should be the default like on all other
architectures - only if needed it should be possible to switch  on  a
don't-use-libgcc  mode,  but  this  should  then  be  independent  of
architecture, either.

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

That would be a board specific thing, which is inappropriate,  as  it
does  not  depend on a specific board. The selection could be done by
passing some argument or environment variables to "make", though.

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

Even if it's maintained in Linux, we still have to follow any changes
there, and port these to U-Boot, and analyse each new problem popping
up by future uses of C statements that cause GCC to generate libgcc
calls - that may or may not be covered by the kernel provided code.

No matter where we get the code from, an ongoing effort will be
needed to maintain this.

> Yes. I talk about "broken tool chains == ARM tool chains". Nothing 

This is where I disagree. Why should we automatically assume that
there are no sane ARM toolchains?

We should always assume to have a usable toolchain  first,  and  only
fall  back  on the workaround if it's really necessary - no matter if
it's ARM or anything else.

Binding this to ARM is IMHO inherently wrong.

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
That said, there may be good reasons for what you did beyond obsequi-
ous sycophantic parody. Perhaps you might be so kind as to elucidate.
         -- Tom Christiansen in <5ldjbm$jtk$1 at csnews.cs.colorado.edu>