The new ELF decoding logic assumed that the target binary has the same
endianness as the host, which broke building ARM64 firmware binaries on
big-endian machines.
This commit fixes the ELF64 decoding to be host-endianness-neutral, and
applies the same changes to the ELF32 decoding. It does not fix the
microblaze-specific dynamic symbol decoding.
It also corrects the functions used for byte swapping in rela_elf64()
and rela_elf32(). The result is the same, but semantically the code is
converting bytes read from a foreign-endianness file to host byte order.
Fixes: 4c9e2d6434 ("tools: relocate-rela: Read rela start/end directly from ELF")
Fixes: a1405d9cfe ("tools: relocate-rela: Check that relocation works only for EM_AARCH64")
Signed-off-by: Samuel Holland <samuel@sholland.org>
Link: https://lore.kernel.org/r/20220715064026.54551-1-samuel@sholland.org
Signed-off-by: Michal Simek <michal.simek@amd.com>
Microblaze is 32bit that's why it is using elf32 format. Relocation code
requires to get information about rela and dynsym senctions and also text
base which was used for compilation.
Code build with -fPIC and linked with -pic generates 4 relocation types.
R_MICROBLAZE_NONE is the easiest one which doesn't require any action.
R_MICROBLAZE_REL only requires write addend to r_offset address.
R_MICROBLAZE_32/R_MICROBLAZE_GLOB_DAT are the most complicated. There is a
need to find out symbol value with adding symbol value and write it to
address pointed by r_offset. Calculation with addend is also added but
only 0 addend values are generated now.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/9912c3d76933bdf75e1ebb6aab43726cd32cafb5.1655299267.git.michal.simek@amd.com
Adding support for new type requires to change code layout that's why move
elf64 code to own function for easier maintenance.
It also solves the problem with not calling fclose in case of error.
Return value from rela_elf64 is saved to variable that's why fclose() is
called all the time.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/21763b80527521c85ca7d4ac64ad6ff4885409c8.1655299267.git.michal.simek@amd.com
There is no need to pass section information via parameters.
Let's read text base and rela start/end directly from elf.
It will help with reading other information from ELF for others
architecture. Input to relocate-rela is u-boot binary and u-boot ELF.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/ab7ae14a6e058722e8c608089729e98edf20a08d.1655299267.git.michal.simek@amd.com
Cap end of relocations by the binary size.
Linkers like to insert some auxiliary sections between .rela.dyn and
.bss_start. These sections don't make their way to the final binary, but
reloc_rela still tries to relocate them, resulting in attempted read
past the end of file.
When linking U-Boot with ld.lld, the STATIC_RELA feature (enabled by
default on arm64) breaks the build. After this patch, U-Boot can be
linked successfully with and without CONFIG_STATIC_RELA.
Originally-from: Elena Petrova <lenaptr@google.com>
Signed-off-by: Alistair Delva <adelva@google.com>
Cc: David Brazdil <dbrazdil@google.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Tom Rini <trini@konsulko.com>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have multiple licenses (in
these cases, dual license) declared in the SPDX-License-Identifier tag.
In this case we change from listing "LICENSE-A LICENSE-B" or "LICENSE-A
or LICENSE-B" or "(LICENSE-A OR LICENSE-B)" to "LICENSE-A OR LICENSE-B"
as per the Linux Kernel style document. Note that parenthesis are
allowed so when they were used before we continue to use them.
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Use the endian macros from u-boot's compiler.h instead of duplicating
the definitions.
This also avoids a build error on OpenBSD by removing swap64 which
collides with a system definition in endian.h pulled in by inttypes.h.
Signed-off-by: Jonathan Gray <jsg@jsg.id.au>
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>
Signed-off-by: David Feng <fenghua@phytium.com.cn>
