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

[Albert ARIBAUD]

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? :/

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)?

OTOH, I don't have an EABI doc for arm64. Could someone just
copy-paster its URL to me? Thanks in advance.

> 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?

Amicalement,
-- 
Albert.