why differentiate .rel.text and .rel.data section?

user_9623401 0
Viewed 1566

Below is a picture that depicting the format of ELF relocatable object file: enter image description here

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)?

elf linker gcc c
1 Answers

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.

user_3798970
Related