Dear Dirk,
In message <4a59f95a.6060...@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
--
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
"Why waste negative entropy on comments, when you could use the same
entropy to create bugs instead?" - Steve Elias
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
