[U-Boot] [PATCH 1/4] arm64: Add tool to statically apply RELA relocations

[Scott Wood]

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 at 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.

-Scott