Dear Dirk Behme,
In message <4a5a0b5b.2010...@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: w...@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$jt...@csnews.cs.colorado.edu>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
