Reputation:
Below is a picture that depicting the format of ELF relocatable object file:
we know that .rel.text
and .rel.data
section contain relocation entries that the linker needs to relocate in order to produce the final executable file.
My question is, why differentiate .rel.text
and .rel.data
section? isn't that more concise that we can combine .rel.text
and .rel.data
section into one section (e.g .rel
)? and we just need to add a single bit in relocation entries struct (Elf64_Rela
) to indicate if the relocation entrie related to functions (.text
) or global variables (.data
)?
Upvotes: 5
Views: 3897
Reputation: 215287
In relocatable (.o
) ELF files (as opposed to linked executable or shared library files with dynamic relocations), there is no unified address space; all addresses are relative to a particular section. Thus each section with relocations in it needs its own relocation table, whose addresses will be relative to that section's base.
It would not suffice, as you asked, to have a single bit for each relocation indicating if it's for .text
or .data
because these are only two of a potentially unlimited (well, limited only by size of index and other such constraints) number of sections. For example with -ffunction-sections
and/or -fdata-sections
, each function or data object will reside in its own section (and thereby need its own relocation table). And with debug information, each debugging-related section will also need its own relocation. Same goes for unwind tables. And so on.
So, in order to avoid having multiple tables, you'd need not just one bit but a whole section index for each relocation. That's a huge O(n)
(here n
is number of relocations) size cost compared to just the O(1)
(for a fixed number of sections) or O(m)
(where m
is the number of sections, which is much less than the number of relocations in any reasonable usage) cost of doing it the way it's done.
Upvotes: 6