[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Masahiro Yamada]

Hi Wolfgang,


2015-07-02 16:34 GMT+09:00 Wolfgang Denk <wd at denx.de>:
> Dear Albert,
>
> In message <20150702000427.562195b4 at lilith> you wrote:
>>
>> > CONFIG_USE_PRIVATE_LIBGCC should only be an emergency-opt-in, but
>> > never ever a default setting.
>>
>> Well then, should we not revisit commits c3dd823 and 7bfd5ee, which
>> enable CONFIG_USE_PRIVATE_LIBGCC for sh and mips respectively? Either
>> we allow it by default for all architectures, or we forbid it by
>> default for all architectures, but I don't like the idea of a
>> heterogeneous per-arch default setting.
>
> Agreed.  I'm really unhappy that I missed these commits (but I have to
> admit that I don't look too closely at these architectures).
>
> Adding Daniel and Nobuhiro to the address list.
>
> Please correct me if I'm wrong:
>
> - SH: Commit c3dd823 looks as if there was no strong reason for this
>   change, it sounds more like "this works now, so let's do it
>   always".
>
>   Is this correct?  Then there would be no strong feelings to revert
>   this commit?

No.

I turned on CONFIG_USE_PRIVATE_LIBGCC for SuperH
because more boards succeeded to build with the private library.


If I revert c3dd823, I get the following error on some boards
and with some toolchains.

/opt/crosstools/sh4-gentoo-linux-gnu/bin/sh4-gentoo-linux-gnu-ld.bfd:
/opt/crosstools/sh4-gentoo-linux-gnu/libexec/gcc/sh4-gentoo-linux-gnu/4.7.1/../../../../lib/gcc/sh4-gentoo-linux-gnu/4.7.1/libgcc.a(_movmem.o):
compiled for a little endian system and target is big endian



> - MIPS: Commit 7bfd5ee is more complicatred.  MIPS is one of the few
>   architectures (the only one?) were we have both big endian and
>   little endian configurations.  This is easy to support within a tool
>   chain.  But do we really have MIPS boards that use hard-float? And
>   if so, why would that be the case?  U-Boot should not contain any
>   floating point code - if it does, this is an error that needs
>   fixing.  As such, this should be a non-issue.
>
>   I would expect that any somewhat recent tool chain is now able to
>   support building of both BE and LE MIPS configurations - which are
>   the ones that casue problems here?
>

In my understanding, SuperH is also dual-endian architecture.
So, I think the situation is similar to MIPS.

SH2 is fixed to big-endian, but SH3 and later support both big and little.


Nobuhiro - please correct me if I am wrong.


-- 
Best Regards
Masahiro Yamada