[U-Boot] [PATCH 0/4] arm64: rela relocation
This lets us remove the manual relocation stuff from the arm64 patchset (the symbol itself is removed by this patchset, but not all the new manual relocations added by the arm64 patchset).
I'm not terribly happy with the way relocate-rela is now, versus something cleaner that operates on the ELF file, but it's good enough for now and waiting longer to get rid of the manual relocations would be worse.
This patchset is based on David's arm64 patchset v13. David, the first two patches should be applied before your arm64 patches. Maybe the fourth as well (except for the removal of the arm64 ifdef you added, which would then need to be squashed with your patch). The third patch should be squashed with your patches (plus you should remove the manual relocs).
Scott Wood (4): arm64: Add tool to statically apply RELA relocations arm64: Turn u-boot.bin back into an ELF file after relocate-rela arm64: Non-manual relocation arm64: Make checkarmreloc accept arm64 relocations
Makefile | 39 ++++++-- arch/arm/config.mk | 4 - arch/arm/cpu/armv8/config.mk | 1 - arch/arm/cpu/armv8/u-boot.lds | 32 +++++-- arch/arm/include/asm/config.h | 5 -- arch/arm/lib/crt0_64.S | 7 +- arch/arm/lib/relocate_64.S | 41 ++++----- include/configs/vexpress_aemv8a.h | 3 + tools/Makefile | 6 ++ tools/relocate-rela.c | 185 ++++++++++++++++++++++++++++++++++++++ 10 files changed, 276 insertions(+), 47 deletions(-) create mode 100644 tools/relocate-rela.c
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.
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.
Signed-off-by: Scott Wood scottwood@freescale.com --- Makefile | 12 ++++ tools/Makefile | 6 ++ tools/relocate-rela.c | 185 ++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 203 insertions(+) create mode 100644 tools/relocate-rela.c
diff --git a/Makefile b/Makefile index 07abef4..5024dd8 100644 --- a/Makefile +++ b/Makefile @@ -392,6 +392,17 @@ else BOARD_SIZE_CHECK = endif
+# Statically apply RELA-style relocations (currently arm64 only) +ifneq ($(CONFIG_STATIC_RELA),) +# $(1) is u-boot ELF, $(2) is u-boot bin, $(3) is text base +DO_STATIC_RELA = \ + start=$$($(NM) $(1) | grep __rel_dyn_start | cut -f 1 -d ' '); \ + end=$$($(NM) $(1) | grep __rel_dyn_end | cut -f 1 -d ' '); \ + $(obj)tools/relocate-rela $(2) $(3) $$start $$end +else +DO_STATIC_RELA = +endif + # Always append ALL so that arch config.mk's can add custom ones ALL-y += $(obj)u-boot.srec $(obj)u-boot.bin $(obj)System.map
@@ -431,6 +442,7 @@ $(obj)u-boot.srec: $(obj)u-boot
$(obj)u-boot.bin: $(obj)u-boot $(OBJCOPY) ${OBJCFLAGS} -O binary $< $@ + $(call DO_STATIC_RELA,$<,$@,$(CONFIG_SYS_TEXT_BASE)) $(BOARD_SIZE_CHECK)
$(obj)u-boot.ldr: $(obj)u-boot diff --git a/tools/Makefile b/tools/Makefile index c36cde2..a5eb85e 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -59,6 +59,7 @@ BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX) BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX) BIN_FILES-$(CONFIG_KIRKWOOD) += kwboot$(SFX) BIN_FILES-y += proftool(SFX) +BIN_FILES-$(CONFIG_STATIC_RELA) += relocate-rela$(SFX)
# Source files which exist outside the tools directory EXT_OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += common/env_embedded.o @@ -84,6 +85,7 @@ NOPED_OBJ_FILES-y += os_support.o NOPED_OBJ_FILES-y += pblimage.o NOPED_OBJ_FILES-y += proftool.o NOPED_OBJ_FILES-y += ublimage.o +NOPED_OBJ_FILES-y += relocate-rela.o OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += envcrc.o OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o OBJ_FILES-$(CONFIG_CMD_NET) += gen_eth_addr.o @@ -250,6 +252,10 @@ $(obj)kwboot$(SFX): $(obj)kwboot.o $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^ $(HOSTSTRIP) $@
+$(obj)relocate-rela$(SFX): $(obj)relocate-rela.o + $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^ + $(HOSTSTRIP) $@ + # Some of the tool objects need to be accessed from outside the tools directory $(obj)%.o: $(SRCTREE)/common/%.c $(HOSTCC) -g $(HOSTCFLAGS_NOPED) -c -o $@ $< diff --git a/tools/relocate-rela.c b/tools/relocate-rela.c new file mode 100644 index 0000000..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 = 0xffffffffULL; /* 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 + default: + fprintf(stderr, "warning: unsupported relocation type %" + PRIu32 " at %" PRIx64 "\n", + type, rela->r_offset); + + return false; + } +} + +static inline uint64_t swap64(uint64_t val) +{ + return ((val >> 56) & 0x00000000000000ffULL) | + ((val >> 40) & 0x000000000000ff00ULL) | + ((val >> 24) & 0x0000000000ff0000ULL) | + ((val >> 8) & 0x00000000ff000000ULL) | + ((val << 8) & 0x000000ff00000000ULL) | + ((val << 24) & 0x0000ff0000000000ULL) | + ((val << 40) & 0x00ff000000000000ULL) | + ((val << 56) & 0xff00000000000000ULL); +} + +#if __BYTE_ORDER == __LITTLE_ENDIAN +static inline uint64_t be64(uint64_t val) +{ + return swap64(val); +} + +static inline uint64_t le64(uint64_t val) +{ + return val; +} +#else +static inline uint64_t le64(uint64_t val) +{ + return swap64(val); +} + +static inline uint64_t be64(uint64_t val) +{ + return val; +} +#endif + +static bool read_num(const char *str, uint64_t *num) +{ + char *endptr; + *num = strtoull(str, &endptr, 16); + return str[0] && !endptr[0]; +} + +int main(int argc, char **argv) +{ + FILE *f; + int i, num; + uint64_t rela_start, rela_end, text_base; + + if (argc != 5) { + fprintf(stderr, "Statically apply ELF rela relocations\n"); + fprintf(stderr, "Usage: %s <bin file> <text base> <rela start> <rela end>\n", + argv[0]); + fprintf(stderr, "All numbers in hex.\n"); + return 1; + } + + f = fopen(argv[1], "r+b"); + if (!f) { + fprintf(stderr, "%s: Cannot open %s: %s\n", + argv[0], argv[1], strerror(errno)); + return 2; + } + + if (!read_num(argv[2], &text_base) || + !read_num(argv[3], &rela_start) || + !read_num(argv[4], &rela_end)) { + fprintf(stderr, "%s: bad number\n", argv[0]); + return 3; + } + + if (rela_start > rela_end || rela_start < text_base || + (rela_end - rela_start) % 24) { + fprintf(stderr, "%s: bad rela bounds\n", argv[0]); + return 3; + } + + rela_start -= text_base; + rela_end -= text_base; + + num = (rela_end - rela_start) / sizeof(Elf64_Rela); + + for (i = 0; i < num; i++) { + Elf64_Rela rela, swrela; + uint64_t pos = rela_start + sizeof(Elf64_Rela) * i; + uint64_t addr; + + if (fseek(f, pos, SEEK_SET) < 0) { + fprintf(stderr, "%s: %s: seek to %" PRIx64 + " failed: %s\n", + argv[0], argv[1], pos, strerror(errno)); + } + + if (fread(&rela, sizeof(rela), 1, f) != 1) { + fprintf(stderr, "%s: %s: read rela failed at %" + PRIx64 "\n", + argv[0], argv[1], pos); + return 4; + } + + swrela.r_offset = le64(rela.r_offset); + swrela.r_info = le64(rela.r_info); + swrela.r_addend = le64(rela.r_addend); + + if (!supported_rela(&swrela)) + continue; + + debug("Rela %" PRIx64 " %" PRIu64 " %" PRIx64 "\n", + swrela.r_offset, swrela.r_info, swrela.r_addend); + + if (swrela.r_offset < text_base) { + fprintf(stderr, "%s: %s: bad rela at %" PRIx64 "\n", + argv[0], argv[1], pos); + return 4; + } + + addr = swrela.r_offset - text_base; + + if (fseek(f, addr, SEEK_SET) < 0) { + fprintf(stderr, "%s: %s: seek to %" + PRIx64 " failed: %s\n", + argv[0], argv[1], addr, strerror(errno)); + } + + if (fwrite(&rela.r_addend, sizeof(rela.r_addend), 1, f) != 1) { + fprintf(stderr, "%s: %s: write failed at %" PRIx64 "\n", + argv[0], argv[1], addr); + return 4; + } + } + + if (fclose(f) < 0) { + fprintf(stderr, "%s: %s: close failed: %s\n", + argv[0], argv[1], strerror(errno)); + return 4; + } + + return 0; +}
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,
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
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? :/
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,
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.
-Scott
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,
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
Hi Scott,
On Tue, 8 Oct 2013 11:22:15 -0500, Scott Wood scottwood@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,
diff --git a/tools/relocate-rela.c b/tools/relocate-rela.c new file mode 100644 index 0000000..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 = 0xffffffffULL; /* 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
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 0000000..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 = 0xffffffffULL; /* 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
While performing relocations on u-boot.bin should be good enough for booting on real hardware, some simulators insist on booting an ELF file (and yet don't perform ELF relocations), so convert the relocated binary back into an ELF file. This can go away in the future if we change relocate-rela to operate directly on the ELF file, or if and when we stop caring about a simulator with this restriction.
Signed-off-by: Scott Wood scottwood@freescale.com --- Makefile | 13 +++++++++++++ 1 file changed, 13 insertions(+)
diff --git a/Makefile b/Makefile index 5024dd8..1938f60 100644 --- a/Makefile +++ b/Makefile @@ -415,6 +415,7 @@ ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb $(obj)u-boot-dtb.bin ifneq ($(CONFIG_SPL_TARGET),) ALL-$(CONFIG_SPL) += $(obj)$(subst ",,$(CONFIG_SPL_TARGET)) endif +ALL-$(CONFIG_REMAKE_ELF) += $(obj)u-boot.elf
# enable combined SPL/u-boot/dtb rules for tegra ifneq ($(CONFIG_TEGRA),) @@ -581,6 +582,18 @@ $(obj)u-boot-img-spl-at-end.bin: $(obj)spl/u-boot-spl.bin $(obj)u-boot.img conv=notrunc 2>/dev/null cat $(obj)u-boot-pad.img $(obj)spl/u-boot-spl.bin > $@
+# Create a new ELF from a raw binary file. This is useful for arm64 +# where static relocation needs to be performed on the raw binary, +# but certain simulators only accept an ELF file (but don't do the +# relocation). +# FIXME refactor dts/Makefile to share target/arch detection +$(obj)u-boot.elf: $(obj)u-boot.bin + @$(OBJCOPY) -B aarch64 -I binary -O elf64-littleaarch64 \ + $< $(obj)u-boot-elf.o + @$(LD) $(obj)u-boot-elf.o -o $@ \ + --defsym=_start=$(CONFIG_SYS_TEXT_BASE) \ + -Ttext=$(CONFIG_SYS_TEXT_BASE) + ifeq ($(CONFIG_SANDBOX),y) GEN_UBOOT = \ cd $(LNDIR) && $(CC) $(SYMS) -T $(obj)u-boot.lds \
This turns off CONFIG_NEEDS_MANUAL_RELOC and turns on -pie.
The bss part of the linker script is changed to be more like arm32, as the previous arm64 approach was generating bad relocations (even readelf didn't like them).
relocate_64.S is made to look more like relocate.S, and then changed to support RELA style relocations rather than REL.
Signed-off-by: Scott Wood scottwood@freescale.com --- arch/arm/config.mk | 2 -- arch/arm/cpu/armv8/config.mk | 1 - arch/arm/cpu/armv8/u-boot.lds | 32 +++++++++++++++++++++++------- arch/arm/include/asm/config.h | 5 ----- arch/arm/lib/crt0_64.S | 7 ++----- arch/arm/lib/relocate_64.S | 41 ++++++++++++++++++++------------------- include/configs/vexpress_aemv8a.h | 3 +++ 7 files changed, 51 insertions(+), 40 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 95c07ad..96d2d88 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -74,9 +74,7 @@ endif endif
# needed for relocation -ifndef CONFIG_ARM64 LDFLAGS_u-boot += -pie -endif
# # FIXME: binutils versions < 2.22 have a bug in the assembler where diff --git a/arch/arm/cpu/armv8/config.mk b/arch/arm/cpu/armv8/config.mk index 9f36d59..027a68c 100644 --- a/arch/arm/cpu/armv8/config.mk +++ b/arch/arm/cpu/armv8/config.mk @@ -13,4 +13,3 @@ PLATFORM_NO_UNALIGNED := $(PF_NO_UNALIGNED) PF_CPPFLAGS_ARMV8 := $(call cc-option, -march=armv8-a) PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARMV8) PLATFORM_CPPFLAGS += $(PF_NO_UNALIGNED) -PLATFORM_CPPFLAGS += -fpic diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds index 328d477..4c12222 100644 --- a/arch/arm/cpu/armv8/u-boot.lds +++ b/arch/arm/cpu/armv8/u-boot.lds @@ -41,25 +41,43 @@ SECTIONS }
. = ALIGN(8); - .reloc : { - __rel_got_start = .; - *(.got) - __rel_got_end = .; - }
.image_copy_end : { *(.__image_copy_end) }
+ . = ALIGN(8); + + .rel_dyn_start : + { + *(.__rel_dyn_start) + } + + .rela.dyn : { + *(.rela*) + } + + .rel_dyn_end : + { + *(.__rel_dyn_end) + } + _end = .;
. = ALIGN(8); + + .bss_start : { + KEEP(*(.__bss_start)); + } + .bss : { - __bss_start = .; *(.bss*) . = ALIGN(8); - __bss_end = .; + } + + .bss_end : { + KEEP(*(.__bss_end)); }
/DISCARD/ : { *(.dynsym) } diff --git a/arch/arm/include/asm/config.h b/arch/arm/include/asm/config.h index 0ee131d..de4d01e 100644 --- a/arch/arm/include/asm/config.h +++ b/arch/arm/include/asm/config.h @@ -11,11 +11,6 @@ #define CONFIG_SYS_BOOT_RAMDISK_HIGH
#ifdef CONFIG_ARM64 -/* - * Currently, GOT is used to relocate u-boot and - * configuration CONFIG_NEEDS_MANUAL_RELOC is needed. - */ -#define CONFIG_NEEDS_MANUAL_RELOC #define CONFIG_PHYS_64BIT #endif
diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S index ddd46eb..7756396 100644 --- a/arch/arm/lib/crt0_64.S +++ b/arch/arm/lib/crt0_64.S @@ -94,11 +94,8 @@ relocation_return: /* * Clear BSS section */ - ldr x9, [x18, #GD_RELOC_OFF] /* x9 <- gd->reloc_off */ - ldr x0, =__bss_start - add x0, x0, x9 /* x0 <- __bss_start in RAM */ - ldr x1, =__bss_end - add x1, x1, x9 /* x1 <- __bss_end in RAM */ + ldr x0, =__bss_start /* this is auto-relocated! */ + ldr x1, =__bss_end /* this is auto-relocated! */ mov x2, #0 clear_loop: str x2, [x0] diff --git a/arch/arm/lib/relocate_64.S b/arch/arm/lib/relocate_64.S index 29c3239..7fba9e2 100644 --- a/arch/arm/lib/relocate_64.S +++ b/arch/arm/lib/relocate_64.S @@ -16,40 +16,41 @@ * void relocate_code (addr_moni) * * This function relocates the monitor code. - * - * NOTE: - * GOT is used and configuration CONFIG_NEEDS_MANUAL_RELOC is needed. + * x0 holds the destination address. */ ENTRY(relocate_code) /* * Copy u-boot from flash to RAM */ - ldr x1, =__image_copy_start /* x1 <- copy source */ - cmp x1, x0 + ldr x1, =__image_copy_start /* x1 <- SRC &__image_copy_start */ + subs x9, x0, x1 /* x9 <- relocation offset */ b.eq relocate_done /* skip relocation */ - mov x2, x0 /* x2 <- copy destination */ - ldr x3, =__image_copy_end /* x3 <- source end address */ + ldr x2, =__image_copy_end /* x2 <- SRC &__image_copy_end */
copy_loop: ldp x10, x11, [x1], #16 /* copy from source address [x1] */ - stp x10, x11, [x2], #16 /* copy to target address [x2] */ - cmp x1, x3 /* until source end address [x3] */ + stp x10, x11, [x0], #16 /* copy to target address [x0] */ + cmp x1, x2 /* until source end address [x2] */ b.lo copy_loop
/* - * Fix .reloc relocations + * Fix .rela.dyn relocations */ - ldr x9, [x18, #GD_RELOC_OFF]/* x9 <- relocation offset */ - ldr x1, =__rel_got_start /* x1 <- rel got start ofs */ - add x1, x1, x9 /* x1 <- rel got start in RAM */ - ldr x2, =__rel_got_end /* x2 <- rel got end ofs */ - add x2, x2, x9 /* x2 <- rel got end in RAM */ + ldr x2, =__rel_dyn_start /* x2 <- SRC &__rel_dyn_start */ + ldr x3, =__rel_dyn_end /* x3 <- SRC &__rel_dyn_end */ fixloop: - ldr x10, [x1] - add x10, x10, x9 /* x10 <- address to be fixed up */ - str x10, [x1] - add x1, x1, #8 /* each got entry is 8 bytes */ - cmp x1, x2 + ldp x0, x1, [x2], #16 /* (x0,x1) <- (SRC location, fixup) */ + ldr x4, [x2], #8 /* x4 <- addend */ + and x1, x1, #0xffffffff + cmp x1, #1027 /* relative fixup? */ + bne fixnext + + /* relative fix: store addend plus offset at dest location */ + add x0, x0, x9 + add x4, x4, x9 + str x4, [x0] +fixnext: + cmp x2, x3 b.lo fixloop
relocate_done: diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 01c95f5..3932e00 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -10,6 +10,9 @@
#define DEBUG
+#define CONFIG_REMAKE_ELF +#define CONFIG_STATIC_RELA + /*#define CONFIG_BOOTING_EL1*/
/*#define CONFIG_SYS_GENERIC_BOARD*/
This turns off CONFIG_NEEDS_MANUAL_RELOC and turns on -pie.
The bss part of the linker script is changed to be more like arm32, as the previous arm64 approach was generating bad relocations (even readelf didn't like them).
relocate_64.S is made to look more like relocate.S, and then changed to support RELA style relocations rather than REL.
Signed-off-by: Scott Wood scottwood@freescale.com
arch/arm/config.mk | 2 -- arch/arm/cpu/armv8/config.mk | 1 - arch/arm/cpu/armv8/u-boot.lds | 32 +++++++++++++++++++++++------- arch/arm/include/asm/config.h | 5 ----- arch/arm/lib/crt0_64.S | 7 ++----- arch/arm/lib/relocate_64.S | 41 ++++++++++++++++++++------------------- include/configs/vexpress_aemv8a.h | 3 +++ 7 files changed, 51 insertions(+), 40 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 95c07ad..96d2d88 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -74,9 +74,7 @@ endif endif
# needed for relocation -ifndef CONFIG_ARM64 LDFLAGS_u-boot += -pie -endif
# # FIXME: binutils versions < 2.22 have a bug in the assembler where diff --git a/arch/arm/cpu/armv8/config.mk b/arch/arm/cpu/armv8/config.mk index 9f36d59..027a68c 100644 --- a/arch/arm/cpu/armv8/config.mk +++ b/arch/arm/cpu/armv8/config.mk @@ -13,4 +13,3 @@ PLATFORM_NO_UNALIGNED := $(PF_NO_UNALIGNED) PF_CPPFLAGS_ARMV8 := $(call cc-option, -march=armv8-a) PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARMV8) PLATFORM_CPPFLAGS += $(PF_NO_UNALIGNED) -PLATFORM_CPPFLAGS += -fpic diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds index 328d477..4c12222 100644 --- a/arch/arm/cpu/armv8/u-boot.lds +++ b/arch/arm/cpu/armv8/u-boot.lds @@ -41,25 +41,43 @@ SECTIONS }
. = ALIGN(8);
.reloc : {
__rel_got_start = .;*(.got)__rel_got_end = .;}
.image_copy_end : { *(.__image_copy_end) }
. = ALIGN(8);
.rel_dyn_start :
{
*(.__rel_dyn_start)}
.rela.dyn : {
*(.rela*)}
.rel_dyn_end :
{
*(.__rel_dyn_end)}
_end = .;
. = ALIGN(8);
.bss_start : {
KEEP(*(.__bss_start));}
.bss : {
__bss_start = .;__bss_end = .;
}
.bss_end : {
KEEP(*(.__bss_end));}
/DISCARD/ : { *(.dynsym) }
diff --git a/arch/arm/include/asm/config.h b/arch/arm/include/asm/config.h index 0ee131d..de4d01e 100644 --- a/arch/arm/include/asm/config.h +++ b/arch/arm/include/asm/config.h @@ -11,11 +11,6 @@ #define CONFIG_SYS_BOOT_RAMDISK_HIGH
#ifdef CONFIG_ARM64 -/*
- Currently, GOT is used to relocate u-boot and
- configuration CONFIG_NEEDS_MANUAL_RELOC is needed.
- */
-#define CONFIG_NEEDS_MANUAL_RELOC #define CONFIG_PHYS_64BIT #endif
diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S index ddd46eb..7756396 100644 --- a/arch/arm/lib/crt0_64.S +++ b/arch/arm/lib/crt0_64.S @@ -94,11 +94,8 @@ relocation_return: /*
- Clear BSS section
*/
- ldr x9, [x18, #GD_RELOC_OFF] /* x9 <- gd->reloc_off */
- ldr x0, =__bss_start
- add x0, x0, x9 /* x0 <- __bss_start in RAM */
- ldr x1, =__bss_end
- add x1, x1, x9 /* x1 <- __bss_end in RAM */
- ldr x0, =__bss_start /* this is auto-relocated! */
- ldr x1, =__bss_end /* this is auto-relocated! */ mov x2, #0
clear_loop: str x2, [x0] diff --git a/arch/arm/lib/relocate_64.S b/arch/arm/lib/relocate_64.S index 29c3239..7fba9e2 100644 --- a/arch/arm/lib/relocate_64.S +++ b/arch/arm/lib/relocate_64.S @@ -16,40 +16,41 @@
- void relocate_code (addr_moni)
- This function relocates the monitor code.
- NOTE:
- GOT is used and configuration CONFIG_NEEDS_MANUAL_RELOC is needed.
*/
- x0 holds the destination address.
ENTRY(relocate_code) /* * Copy u-boot from flash to RAM */
- ldr x1, =__image_copy_start /* x1 <- copy source */
- cmp x1, x0
- ldr x1, =__image_copy_start /* x1 <- SRC &__image_copy_start */
- subs x9, x0, x1 /* x9 <- relocation offset */ b.eq relocate_done /* skip relocation */
- mov x2, x0 /* x2 <- copy destination */
- ldr x3, =__image_copy_end /* x3 <- source end address */
- ldr x2, =__image_copy_end /* x2 <- SRC &__image_copy_end */
copy_loop: ldp x10, x11, [x1], #16 /* copy from source address [x1] */
- stp x10, x11, [x2], #16 /* copy to target address [x2] */
- cmp x1, x3 /* until source end address [x3] */
stp x10, x11, [x0], #16 /* copy to target address [x0] */
cmp x1, x2 /* until source end address [x2] */ b.lo copy_loop
/*
* Fix .reloc relocations
* Fix .rela.dyn relocations
- ldr x9, [x18, #GD_RELOC_OFF]/* x9 <- relocation offset */
- ldr x1, =__rel_got_start /* x1 <- rel got start ofs */
- add x1, x1, x9 /* x1 <- rel got start in RAM */
- ldr x2, =__rel_got_end /* x2 <- rel got end ofs */
- add x2, x2, x9 /* x2 <- rel got end in RAM */
- ldr x2, =__rel_dyn_start /* x2 <- SRC &__rel_dyn_start */
- ldr x3, =__rel_dyn_end /* x3 <- SRC &__rel_dyn_end */
fixloop:
- ldr x10, [x1]
- add x10, x10, x9 /* x10 <- address to be fixed up */
- str x10, [x1]
- add x1, x1, #8 /* each got entry is 8 bytes */
- cmp x1, x2
- ldp x0, x1, [x2], #16 /* (x0,x1) <- (SRC location, fixup) */
- ldr x4, [x2], #8 /* x4 <- addend */
- and x1, x1, #0xffffffff
- cmp x1, #1027 /* relative fixup? */
- bne fixnext
- /* relative fix: store addend plus offset at dest location */
- add x0, x0, x9
- add x4, x4, x9
- str x4, [x0]
+fixnext:
- cmp x2, x3 b.lo fixloop
relocate_done: diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 01c95f5..3932e00 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -10,6 +10,9 @@
#define DEBUG
+#define CONFIG_REMAKE_ELF +#define CONFIG_STATIC_RELA
CONFIG_STATIC_RELA is always needed, How about remove this macro.
David,
On Sat, 2013-10-05 at 00:13 +0800, FengHua wrote:
diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 01c95f5..3932e00 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -10,6 +10,9 @@
#define DEBUG
+#define CONFIG_REMAKE_ELF +#define CONFIG_STATIC_RELA
CONFIG_STATIC_RELA is always needed, How about remove this macro.
It's always needed for arm64, but not for all architectures. I don't want to just use CONFIG_ARM64 because in theory another arch could be added that needs it. Eventually this should be moved out of the board config and into a file that defines general arm64 stuff.
-Scott
Signed-off-by: Scott Wood scottwood@freescale.com --- Makefile | 14 +++++++++----- arch/arm/config.mk | 2 -- 2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile index 1938f60..20d48e9 100644 --- a/Makefile +++ b/Makefile @@ -805,12 +805,16 @@ tools: $(VERSION_FILE) $(TIMESTAMP_FILE) $(MAKE) -C $@ all endif # config.mk
-# ARM relocations should all be R_ARM_RELATIVE. +# ARM relocations should all be R_ARM_RELATIVE (32-bit) or +# R_AARCH64_RELATIVE (64-bit). checkarmreloc: $(obj)u-boot - @if test "R_ARM_RELATIVE" != \ - "`$(CROSS_COMPILE)readelf -r $< | cut -d ' ' -f 4 | grep R_ARM | sort -u`"; \ - then echo "$< contains relocations other than \ - R_ARM_RELATIVE"; false; fi + @RELOC="`$(CROSS_COMPILE)readelf -r -W $< | cut -d ' ' -f 4 | \ + grep R_A | sort -u`"; \ + if test "$$RELOC" != "R_ARM_RELATIVE" -a \ + "$$RELOC" != "R_AARCH64_RELATIVE"; then \ + echo "$< contains unexpected relocations: $$RELOC"; \ + false; \ + fi
$(VERSION_FILE): @mkdir -p $(dir $(VERSION_FILE)) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 96d2d88..ce3903b 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -95,8 +95,6 @@ endif endif
# check that only R_ARM_RELATIVE relocations are generated -ifndef CONFIG_ARM64 ifneq ($(CONFIG_SPL_BUILD),y) ALL-y += checkarmreloc endif -endif
arm64: rela relocation
This lets us remove the manual relocation stuff from the arm64 patchset (the symbol itself is removed by this patchset, but not all the new manual relocations added by the arm64 patchset).
I'm not terribly happy with the way relocate-rela is now, versus something cleaner that operates on the ELF file, but it's good enough for now and waiting longer to get rid of the manual relocations would be worse.
This patchset is based on David's arm64 patchset v13. David, the first two patches should be applied before your arm64 patches. Maybe the fourth as well (except for the removal of the arm64 ifdef you added, which would then need to be squashed with your patch). The third patch should be squashed with your patches (plus you should remove the manual relocs).
Scott Wood (4): arm64: Add tool to statically apply RELA relocations arm64: Turn u-boot.bin back into an ELF file after relocate-rela arm64: Non-manual relocation arm64: Make checkarmreloc accept arm64 relocations
Makefile | 39 ++++++-- arch/arm/config.mk | 4 - arch/arm/cpu/armv8/config.mk | 1 - arch/arm/cpu/armv8/u-boot.lds | 32 +++++-- arch/arm/include/asm/config.h | 5 -- arch/arm/lib/crt0_64.S | 7 +- arch/arm/lib/relocate_64.S | 41 ++++----- include/configs/vexpress_aemv8a.h | 3 + tools/Makefile | 6 ++ tools/relocate-rela.c | 185 ++++++++++++++++++++++++++++++++++++++ 10 files changed, 276 insertions(+), 47 deletions(-) create mode 100644 tools/relocate-rela.c
Great, some fixups related with relocation could be removed. I will modify arm64 patchset according this.
David
Hi FengHua,
On Fri, 4 Oct 2013 23:55:01 +0800 (GMT+08:00), FengHua fenghua@phytium.com.cn wrote:
arm64: rela relocation
This lets us remove the manual relocation stuff from the arm64 patchset (the symbol itself is removed by this patchset, but not all the new manual relocations added by the arm64 patchset).
I'm not terribly happy with the way relocate-rela is now, versus something cleaner that operates on the ELF file, but it's good enough for now and waiting longer to get rid of the manual relocations would be worse.
This patchset is based on David's arm64 patchset v13. David, the first two patches should be applied before your arm64 patches. Maybe the fourth as well (except for the removal of the arm64 ifdef you added, which would then need to be squashed with your patch). The third patch should be squashed with your patches (plus you should remove the manual relocs).
Scott Wood (4): arm64: Add tool to statically apply RELA relocations arm64: Turn u-boot.bin back into an ELF file after relocate-rela arm64: Non-manual relocation arm64: Make checkarmreloc accept arm64 relocations
Makefile | 39 ++++++-- arch/arm/config.mk | 4 - arch/arm/cpu/armv8/config.mk | 1 - arch/arm/cpu/armv8/u-boot.lds | 32 +++++-- arch/arm/include/asm/config.h | 5 -- arch/arm/lib/crt0_64.S | 7 +- arch/arm/lib/relocate_64.S | 41 ++++----- include/configs/vexpress_aemv8a.h | 3 + tools/Makefile | 6 ++ tools/relocate-rela.c | 185 ++++++++++++++++++++++++++++++++++++++ 10 files changed, 276 insertions(+), 47 deletions(-) create mode 100644 tools/relocate-rela.c
Great, some fixups related with relocation could be removed. I will modify arm64 patchset according this.
Stop me if I'm missing something, but doesn't Scott's patch series need yours? And if you remove the manual relocas in yours, doesn't that make your series unable to function properly until Scott's series is applied too?
If I am not mistaken, then maybe Scott's and your patches should be merged in a single series, with adequate attribution of course.
David
Amicalement,
On Sat, 2013-10-05 at 09:55 +0200, Albert ARIBAUD wrote:
Hi FengHua,
On Fri, 4 Oct 2013 23:55:01 +0800 (GMT+08:00), FengHua fenghua@phytium.com.cn wrote:
arm64: rela relocation
This lets us remove the manual relocation stuff from the arm64 patchset (the symbol itself is removed by this patchset, but not all the new manual relocations added by the arm64 patchset).
I'm not terribly happy with the way relocate-rela is now, versus something cleaner that operates on the ELF file, but it's good enough for now and waiting longer to get rid of the manual relocations would be worse.
This patchset is based on David's arm64 patchset v13. David, the first two patches should be applied before your arm64 patches. Maybe the fourth as well (except for the removal of the arm64 ifdef you added, which would then need to be squashed with your patch). The third patch should be squashed with your patches (plus you should remove the manual relocs).
Scott Wood (4): arm64: Add tool to statically apply RELA relocations arm64: Turn u-boot.bin back into an ELF file after relocate-rela arm64: Non-manual relocation arm64: Make checkarmreloc accept arm64 relocations
Makefile | 39 ++++++-- arch/arm/config.mk | 4 - arch/arm/cpu/armv8/config.mk | 1 - arch/arm/cpu/armv8/u-boot.lds | 32 +++++-- arch/arm/include/asm/config.h | 5 -- arch/arm/lib/crt0_64.S | 7 +- arch/arm/lib/relocate_64.S | 41 ++++----- include/configs/vexpress_aemv8a.h | 3 + tools/Makefile | 6 ++ tools/relocate-rela.c | 185 ++++++++++++++++++++++++++++++++++++++ 10 files changed, 276 insertions(+), 47 deletions(-) create mode 100644 tools/relocate-rela.c
Great, some fixups related with relocation could be removed. I will modify arm64 patchset according this.
Stop me if I'm missing something, but doesn't Scott's patch series need yours? And if you remove the manual relocas in yours, doesn't that make your series unable to function properly until Scott's series is applied too?
If I am not mistaken, then maybe Scott's and your patches should be merged in a single series, with adequate attribution of course.
What you're missing is the note above where I suggest merging the two patchsets. :-)
-Scott
Hi FengHua,
On Fri, 4 Oct 2013 23:55:01 +0800 (GMT+08:00), FengHua fenghua@phytium.com.cn wrote:
arm64: rela relocation
This lets us remove the manual relocation stuff from the arm64 patchset (the symbol itself is removed by this patchset, but not all the new manual relocations added by the arm64 patchset).
I'm not terribly happy with the way relocate-rela is now, versus something cleaner that operates on the ELF file, but it's good enough for now and waiting longer to get rid of the manual relocations would be worse.
This patchset is based on David's arm64 patchset v13. David, the first two patches should be applied before your arm64 patches. Maybe the fourth as well (except for the removal of the arm64 ifdef you added, which would then need to be squashed with your patch). The third patch should be squashed with your patches (plus you should remove the manual relocs).
Scott Wood (4): arm64: Add tool to statically apply RELA relocations arm64: Turn u-boot.bin back into an ELF file after relocate-rela arm64: Non-manual relocation arm64: Make checkarmreloc accept arm64 relocations
Makefile | 39 ++++++-- arch/arm/config.mk | 4 - arch/arm/cpu/armv8/config.mk | 1 - arch/arm/cpu/armv8/u-boot.lds | 32 +++++-- arch/arm/include/asm/config.h | 5 -- arch/arm/lib/crt0_64.S | 7 +- arch/arm/lib/relocate_64.S | 41 ++++----- include/configs/vexpress_aemv8a.h | 3 + tools/Makefile | 6 ++ tools/relocate-rela.c | 185 ++++++++++++++++++++++++++++++++++++++ 10 files changed, 276 insertions(+), 47 deletions(-) create mode 100644 tools/relocate-rela.c
Great, some fixups related with relocation could be removed. I will modify arm64 patchset according this.
Stop me if I'm missing something, but doesn't Scott's patch series need yours? And if you remove the manual relocas in yours, doesn't that make your series unable to function properly until Scott's series is applied too?
If I am not mistaken, then maybe Scott's and your patches should be merged in a single series, with adequate attribution of course.
David
Amicalement,
Albert.
Yes, these two patches should work together. We'd better merge them to one patchset. The point is we should make choice between CONFIG_NEED_MANUAL_RELOC and relocation-rela tool before aarch64-gcc support rel relocation format or maybe aarch64-gcc will never do it. Another motivation to update arm64 patch is that it's too old and got wrong when applied to current u-boot master.
Best Regards.
David.
Hi FengHua,
On Tue, 8 Oct 2013 11:32:39 +0800 (GMT+08:00), FengHua fenghua@phytium.com.cn wrote:
Hi FengHua,
On Fri, 4 Oct 2013 23:55:01 +0800 (GMT+08:00), FengHua fenghua@phytium.com.cn wrote:
arm64: rela relocation
This lets us remove the manual relocation stuff from the arm64 patchset (the symbol itself is removed by this patchset, but not all the new manual relocations added by the arm64 patchset).
I'm not terribly happy with the way relocate-rela is now, versus something cleaner that operates on the ELF file, but it's good enough for now and waiting longer to get rid of the manual relocations would be worse.
This patchset is based on David's arm64 patchset v13. David, the first two patches should be applied before your arm64 patches. Maybe the fourth as well (except for the removal of the arm64 ifdef you added, which would then need to be squashed with your patch). The third patch should be squashed with your patches (plus you should remove the manual relocs).
Scott Wood (4): arm64: Add tool to statically apply RELA relocations arm64: Turn u-boot.bin back into an ELF file after relocate-rela arm64: Non-manual relocation arm64: Make checkarmreloc accept arm64 relocations
Makefile | 39 ++++++-- arch/arm/config.mk | 4 - arch/arm/cpu/armv8/config.mk | 1 - arch/arm/cpu/armv8/u-boot.lds | 32 +++++-- arch/arm/include/asm/config.h | 5 -- arch/arm/lib/crt0_64.S | 7 +- arch/arm/lib/relocate_64.S | 41 ++++----- include/configs/vexpress_aemv8a.h | 3 + tools/Makefile | 6 ++ tools/relocate-rela.c | 185 ++++++++++++++++++++++++++++++++++++++ 10 files changed, 276 insertions(+), 47 deletions(-) create mode 100644 tools/relocate-rela.c
Great, some fixups related with relocation could be removed. I will modify arm64 patchset according this.
Stop me if I'm missing something, but doesn't Scott's patch series need yours? And if you remove the manual relocas in yours, doesn't that make your series unable to function properly until Scott's series is applied too?
If I am not mistaken, then maybe Scott's and your patches should be merged in a single series, with adequate attribution of course.
David
Amicalement,
Albert.
Yes, these two patches should work together.
Yep, Scott pointed me to where my eyes would not look. Must have been a SEP field. :)
We'd better merge them to one patchset. The point is we should make choice between CONFIG_NEED_MANUAL_RELOC and relocation-rela tool before aarch64-gcc support rel relocation format or maybe aarch64-gcc will never do it. Another motivation to update arm64 patch is that it's too old and got wrong when applied to current u-boot master.
I am in favor of going for relocation-rela, if only because manual relocations are a major pain in the long run, so I want relocation handling to be automated.
Best Regards.
David.
Amicalement,
participants (3)
-
Albert ARIBAUD -
FengHua -
Scott Wood