[U-Boot] [PATCH] arm: prevent using movt/movw address loads

[Jeroen Hofstee <jeroen@myspectrum.nl>]

Hello Tom,

On 09/19/2013 11:16 PM, Tom Rini wrote:
> On Sat, Aug 24, 2013 at 01:55:38PM +0200, Jeroen Hofstee wrote:
>
>> The movt/movw instruction can be used to hardcode an
>> memory location in the instruction itself. The linker
>> starts complaining about this if the compiler decides
>> to do so: "relocation R_ARM_MOVW_ABS_NC against `a local
>> symbol' can not be used" and it is not support by U-boot
>> as well. Prevent their use by requiring word relocations.
>> This allows u-boot to be build at other optimalization
>> levels then -Os.
>>
>> Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
>> Cc: TigerLiu at viatech.com.cn
>> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
>> ---
>>   arch/arm/config.mk | 8 ++++++--
>>   1 file changed, 6 insertions(+), 2 deletions(-)
> Is this also something we need for llvm?

You guessed that right, for clang actually (llvm has
already been taught to not emit movw/movt pairs,
when requested not to do so). So with the
-mword-relocations || present I can teach clang to tell llvm
not to do it.

I am not aware of any reason why gcc could not
decide to do the same in future releases. A pointer
comparison e.g. is of exactly the same size (afaik).
In this case U-boot will no longer compile without
mentioned flag.

> I am hesitant here because as
> Wolfgang points out, -O0 is usually the wrong way to debug a problem and
> I'll add we're well into the age where debuggers work just fine with
> optimized code.

mmm, I don't share your concern here. Not that I
disagree with what Wolfgang said, but since it is
unrelated to the patch itself. What I read was that
Wolfgang tried to explain to a ML poster without a
proper name that it might be even harder at times to
find a bug at -O0, since it is a different binary and
that it is not considered a bug. I assume the fast
majority of U-boot developers know these to debug
things..

If you really have that little trust in U-boot developers
a more proper way would be to actually create a make
rule checking cflags and point them to a nice debugging
document. And I really hope you don't do that ;)

One thing I can think of in favour of -O0 is for educational
purposes. You can run u-boot in qemu then without the,
at times weird optimized jumps, to get an idea about basic
code flow.

> If there's some -O2 enabled gcc flag we want because of
> a measurable performance win, we should add it specifically to -Os.
>
First of all the default -Os is unchanged and I have no
intention to change it. -O2 won't build without the patch
last time I checked ;)

Anyway, I like the flag since it helps to not special case
clang and it guarantees builds with gcc at all optimisation
levels, now and in the future. I don't care if it goes in this
release or the next one.

Regards,
Jeroen