-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
decodeRelaEntries
sometimes returns fewer relocations than readelf -r
#40
Comments
Reading the ELF spec for But indeed, if there is a decent way of knowing the number of entries / the relevant sections, we may be able to fix this on the fly, though that's a bit annoying. |
Some searching (see here) suggests that the range of memory
Annoyingly, I'm not sure how you'd even know the number of entries without reading the contents of the table first, which is the very thing that I'm trying to do. I'd have to take a look at how |
Reading the /* On some machines, notably SPARC, DT_REL* includes DT_JMPREL in its
range. Note that according to the ELF spec, this is completely legal!
We are guaranteed that we have one of three situations. Either DT_JMPREL
comes immediately after DT_REL*, or there is overlap and DT_JMPREL
consumes precisely the very end of the DT_REL*, or DT_JMPREL and DT_REL*
are completely separate and there is a gap between them. */ That is to say, the implementation of
We would need to do something similar in We should check to see what the behavior of My guess is that |
See GaloisInc/macaw#416 for a similar issue on the |
While adding a test case for #35, I discovered that
elf-edit
'sdecodeRelaEntries
function will return different results for PPC32 binaries versus PPC64 binaries. To pick a concrete example, let's look at this simple C program:I used a
musl
-based PPC32 cross-compiler (obtained from here) and a PPC64 cross-compiler (obtained from here) to compile this program into a PPC32 binary namedppc32-relocs.elf
and a PPC64 binary namedppc64-relocs.elf
, respectively. I can usereadelf -r
to determine the relocations contained in each binary's RELA relocation table:Note that each binaries' RELA relocation table is divided into two sections,
.rela.dyn
and.rela.plt
. This will be important later.If I use
elf-edit
'sdecodeRelaEntries
function onppc32-relocs.elf
, it will return all of the relocations thatreadelf -r
reports. On the other hand, if I usedecodeRelaEntries
onppc64-relocs.elf
, it will only report a subset of the relocations:Notably, all of the
R_PPC64_JMP_SLOT
relocations (contained exclusively within the.rela.plt
section) are absent!The reason this happens is because each binary prescribes different semantics to the
RELASZ
tag. For example, let's look out thereadelf -d ppc32-relocs.elf
tag:elf-edit
determines what part of the binary corresponds to the RELA relocation table by:RELA
(0x2ec
), andRELASZ
(252
)In the
ppc32-relocs.txt
example, this works beautifully. There are 17 entries in the.rela.dyn
section and 4 entries in the.rela.plt
section for a total of 21 entries overall in the relocation table.RELAENT
tells us that each entry is 12 bytes in size, and 21 * 12 = 252, which is exactly the value ofRELASZ
.Things get stranger with
ppc64-relocs.elf
, however:Here, we have a
RELASZ
of 192 bytes. There are 8 entries in the.rela.dyn
section and 4 entries in the.rela.plt
section for a total of 12 entries overall in the relocation table. Moreover,RELAENT
is 24 bytes. But note that 12 * 24 = 288, which exceeds the value ofRELASZ
! In this particular example,RELASZ
only covers the size of the.rela.dyn
section, and it does not cover anything in the.rela.plt
section, which explains why all of the relocations from the.rela.plt
section were omitted. (If you addRELASZ
withPLTRELSZ
, the latter being the size of the.rela.plt
section, then you do in fact get 288 bytes.)What should we do here? The cross-compilers I am using for PPC32 and PPC64 appear to prescribe different semantics to the
RELASZ
tag, which makes it questionable whether that is a reliable way to gauge the overall size of the RELA relocation table. Perhaps we should instead count the number of table entries and multiply it byRELAENT
?The text was updated successfully, but these errors were encountered: