Dear Wolfgang,
Wolfgang Denk wrote:
> 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).
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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
