Hi Scott,
On Mon, 7 Oct 2013 19:55:46 -0500, Scott Wood scottwood@freescale.com wrote:
On Sat, 2013-10-05 at 09:52 +0200, Albert ARIBAUD wrote:
Hi Scott,
On Thu, 3 Oct 2013 17:48:28 -0500, Scott Wood scottwood@freescale.com wrote:
ARM64 uses the newer RELA-style relocations rather than the older REL. RELA relocations have an addend in the relocation struct, rather than expecting the loader to read a value from the location to be updated.
While this is beneficial for ordinary program loading, it's problematic for U-Boot because the location to be updated starts out with zero, rather than a pre-relocation value. Since we need to be able to run C code before relocation, we need a tool to apply the relocations at build time.
I love it when support for a feature which offers more capabilities is replaced with support for one which offers less. What's the point of a relocation system that produces a binary which will *never* work if not relocated first? What's the point of zeroing position-dependent locations instead of putting some useful value in it, like the value they would have if no relocation occurred? :/
Yeah, it's annoying. It also seems to affect gdb printing global variables before a program has started.
I really don't understand why REL-style relocation is impossible. Is it an EABI specification? A toolchain limitation? A toolchain design decision (i.e., a limitation that will not be lifted)?
It looks like one of the latter two. I don't know which. I tried looking at the linker code to see if there was an option to switch, and had difficulty following it. If someone else wants to engage with the binutils people and get a REL option added, that'd be great, but I don't have the bandwidth right now, and in any case it would be a while before we could rely on such a solution.
OTOH, I don't have an EABI doc for arm64. Could someone just copy-paster its URL to me? Thanks in advance.
I don't know of an "E"ABI for arm64, but googling "aarch64 abi" turns up an ELF ABI document as the first result. I tried to copy and paste the URL but it's google-encoded crap, and it's PDF so I can't copy it from the browser window that opens.
That document says that both REL and RELA are acceptable.
In theory this tool is applicable to other newer architectures (mainly 64-bit), but currently the only relocations it supports are for arm64, and it assumes a 64-bit little-endian target. If the latter limitation is ever to be changed, we'll need a way to tell the tool what format the image is in. Eventually this may be replaced by a tool that uses libelf or similar and operates directly on the ELF file. I've written some code for such an approach but libelf does not make it easy to poke addresses by memory address (rather than by section), and I was hesitant to write code to manually parse the program headers and do the update outside of libelf (or to iterate over sections) -- especially since it wouldn't get test coverage on things like binaries with multiple PT_LOAD segments. This should be good enough for now to let the manual relocation stuff be removed from the arm64 patches.
Can you clarify what makes this tool beneficial as opposed to e.g. doing an objcopy from .elf to binary? After all, if we're going to relocate at build time from address A to B, why not directly build for address B, objcopy the resulting ELF and be done with it?
We do use objcopy, but it doesn't apply the relocations. It doesn't matter what address we build for; if the relocations aren't applied, all to-be-relocated pointers will be zero.
Thanks Scott fot the heads-up. I have found the arm64 ABI and traced it back to this URL:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0056b/index.html
(Somehow the document can be read in Firefox but evince chokes on it)
I see that some relocation types are deemed mandatory (4.6.1, page 13) and the way I read it, R_AARCH64_RELATIVE should be one of them...
I'll have a stab at investigating both binutil and gcc.
Meanwhile, even if we end up being able to use R_AARCH64_RELATIVE, part of the patch series will remain useful, notably the filtering in the makefile. I would just like a note added somewhere stating that this is hopefully an interim solution until R_AARCH64_RELATIVE is available.
-Scott
Amicalement,