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

Masahiro Yamada
2015-07-02T12:12:48Z

Hi Wolfgang,

2015-07-02 16:34 GMT+09:00 Wolfgang Denk <wd@denx.de>:
> Dear Albert,
>
> In message <20150702000427.562195b4@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