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

[Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>]

On 20:17 Sun 12 Jul     , Wolfgang Denk wrote:
> Dear Dirk Behme,
> 
> In message <4A5A0B5B.2010408@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.
which is the case no arch are force to switch the current patch just allow
to switch to this mode.
> 
> > > 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?
unfortunately most of the arm toolchains are not sane for every point of view
as you can not build U-Boot, kernel and userland with the same optimized
toolchain most of the time.

Maybe oneday we can assume that we could use any arm toolchain to build the
3, but for now I can assure it's not the case.

On other it maybe not the case but as example on mips we have similar issue
to workaround to be able to build U-Boot & Kernel

Best Regards,
J.