Is relocation in pyelftools ever a nontrivial transform?

[sevaa]

The method get_dwarf_info has an optional parameter relocate_dwarf_sections, defaulting to True.

From what I understand, the purpose of relocating an executable/shared object binary during loading by the operating system's ELF loader is adjusting the data in the sections to work when the starting address differs from the address that the binary was linked with. Now, when pyelftools loads a binary, there is no starting address - or rather, the bits, one loaded, should look as if the binary is loaded at its preferred starting address. Is there any scenario in which relocation is nontrivial (e. g. makes changes to the bits), even if the loading address matches the preferred address?

The reason why I'm asking, in #586 I'm exploring the possibility of short circuiting the DWARF section loading/transforming logic by straightforwardly memory mapping the bits of the binary, and parsing DWARF straight from those mapped chunks. Relocation would get in the way - if it's nontrivial. The way relocation is currently implemented, I don't see an easy way to check if it is.

[eliben]

I guess I don't fully understand the question. What does nontrivial mean, can you use an example to clarify?

[sevaa]

Nontrivial as in altering the section bytes. Adding a zero to a byte at offset is a trivial transform, adding any other number isn't. When I was poking around the flow of relocation in pyelftools, against one of the test binaries, I saw mostly adding zeros.

[eliben]

Well, if the relocation section specifies a non-zero change, that's what will be applied, no? I'm still missing something, I feel.

Do we have tests that exercise relocations? What happens if you just flip relocate_dwarf_sections to False?

[sevaa]

There are two processes that are called relocation: what the linker does when building an executable or a shared library out of object files, and what the loader potentially does when loading an executable or a shared library into a process' address space. We don't have any examples of the latter - no ET_EXEC/ET_DYN binaries in the corpus with relocations against DWARF. I thought we had them.

All we have is object files with relocation records for the linker. Some of those encode trivial transforms (i. e. the writeback value is the same as the value that was there), and that's what caught my eye. I thought the presence of relocations in binaries will effectively render the memory mapping logic pointless (can't memory-map if there are transforms) and sought for a way to elide them, but if DWARF relocations in linked binaries are as rare as our corpus suggests, it's not really a problem. The users are complaining about giant linked binaries, not about giant .o files. Nobody debugs .o files anyway.