Re: [U-Boot] [PATCH 1/4] arm64: Add tool to statically apply RELA relocations
Hi Scott, On Tue, 8 Oct 2013 11:22:15 -0500, Scott Wood scottw...@freescale.com wrote: On Tue, 2013-10-08 at 10:10 +0200, Albert ARIBAUD wrote: 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) It works for me in evince 3.6.1. Thanks. Mine is 3.10.0. Could be a regression. -Scott Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] arm64: Add tool to statically apply RELA relocations
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 EABI 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
Re: [U-Boot] [PATCH 1/4] arm64: Add tool to statically apply RELA relocations
diff --git a/tools/relocate-rela.c b/tools/relocate-rela.c
new file mode 100644
index 000..47afe0b
--- /dev/null
+++ b/tools/relocate-rela.c
@@ -0,0 +1,185 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier: GPL-2.0+ BSD-2-Clause
+ *
+ * 64-bit and little-endian target only until we need to support a different
+ * arch that needs this.
+ */
+
+#include elf.h
+#include errno.h
+#include inttypes.h
+#include stdarg.h
+#include stdbool.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+
+static const bool debug_en;
+
+static void debug(const char *fmt, ...)
+{
+ va_list args;
+
+ va_start(args, fmt);
+ if (debug_en)
+ vprintf(fmt, args);
+}
+
+static bool supported_rela(Elf64_Rela *rela)
+{
+ uint64_t mask = 0xULL; /* would be different on 32-bit */
+ uint32_t type = rela-r_info mask;
+
+ switch (type) {
+#ifdef R_AARCH64_RELATIVE
+ case R_AARCH64_RELATIVE:
+ return true;
+#endif
hi Scott,
the R_AARCH64_RELATIVE is not deinfed in my system. Whether we should
define it at somewhere?
David
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] arm64: Add tool to statically apply RELA relocations
On Tue, 2013-10-08 at 22:22 +0800, FengHua wrote:
diff --git a/tools/relocate-rela.c b/tools/relocate-rela.c
new file mode 100644
index 000..47afe0b
--- /dev/null
+++ b/tools/relocate-rela.c
@@ -0,0 +1,185 @@
+/*
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+ BSD-2-Clause
+ *
+ * 64-bit and little-endian target only until we need to support a
different
+ * arch that needs this.
+ */
+
+#include elf.h
+#include errno.h
+#include inttypes.h
+#include stdarg.h
+#include stdbool.h
+#include stdio.h
+#include stdlib.h
+#include string.h
+
+static const bool debug_en;
+
+static void debug(const char *fmt, ...)
+{
+ va_list args;
+
+ va_start(args, fmt);
+ if (debug_en)
+ vprintf(fmt, args);
+}
+
+static bool supported_rela(Elf64_Rela *rela)
+{
+ uint64_t mask = 0xULL; /* would be different on 32-bit */
+ uint32_t type = rela-r_info mask;
+
+ switch (type) {
+#ifdef R_AARCH64_RELATIVE
+ case R_AARCH64_RELATIVE:
+ return true;
+#endif
hi Scott,
the R_AARCH64_RELATIVE is not deinfed in my system. Whether we should
define it at somewhere?
A newer host elf.h should fix this, but if it's going to be a problem
maybe we should just define it ourselves (value is 1027).
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] arm64: Add tool to statically apply RELA relocations
On Tue, 2013-10-08 at 10:10 +0200, Albert ARIBAUD wrote: 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) It works for me in evince 3.6.1. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] arm64: Add tool to statically apply RELA relocations
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 EABI 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] arm64: Add tool to statically apply RELA relocations
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? :/ 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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] arm64: Add tool to statically apply RELA relocations
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 How it is beneficial than rel format? Why aarch64-gcc use rela format only instead of supporting two format? these confuse me a few months. David, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] arm64: Add tool to statically apply RELA relocations
On Sat, 2013-10-05 at 00:10 +0800, FengHua 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 How it is beneficial than rel format? It avoids the need to read anything other than the rela descriptor, and thus makes relocation faster. Why aarch64-gcc use rela format only instead of supporting two format? these confuse me a few months. It's probably specified by the ABI which type to use, and it's not worth adding toolchain support for something different just for weird cases like this. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
