From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeroen Hofstee Date: Fri, 20 Sep 2013 19:15:29 +0200 Subject: [U-Boot] [PATCH] arm: prevent using movt/movw address loads In-Reply-To: <20130919211629.GC5273@bill-the-cat> References: <1377345338-9695-1-git-send-email-jeroen@myspectrum.nl> <20130919211629.GC5273@bill-the-cat> Message-ID: <523C82B1.4020908@myspectrum.nl> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >> Cc: TigerLiu at viatech.com.cn >> Cc: Albert ARIBAUD >> --- >> 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