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 <jer...@myspectrum.nl>
Cc: tiger...@viatech.com.cn
Cc: Albert ARIBAUD <albert.u.b...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
