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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

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,
-- 
Albert.