Hi Scott, On Mon, 7 Oct 2013 19:55:46 -0500, Scott Wood <scottw...@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 <scottw...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot