4

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

  • Relocation entries don't really have a free bit to steal, but why would you want O(n) extra storage anyway instead of O(1)? – R.. GitHub STOP HELPING ICE Aug 31 '20 at 14:33
  • because .text is read only and .data is read/write so you need them separate so that they can be properly linked. Yes there are cases where they can simply land in the same memory space, but why take control away from the programmer? – old_timer Aug 31 '20 at 14:33
  • 2
    @old_timer: This isn't the text/data sections themselves, just the sections holding the relocations for them. – R.. GitHub STOP HELPING ICE Aug 31 '20 at 14:34
  • could make the same argument for .data and .text and .bss in general – old_timer Aug 31 '20 at 14:34
  • exactly you need to know the difference so you can load/place/link/etc them. – old_timer Aug 31 '20 at 14:35
  • 1
    This question is not opinion-based. Would the close-warriors who don't understand the topic being asked about please cut it out?? There is a clear technical reason here and the question is a useful one for understanding how ELF works. – R.. GitHub STOP HELPING ICE Aug 31 '20 at 15:34

1 Answers1

6

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.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • thanks for your answer, could you also have a look at this question please https://stackoverflow.com/questions/63644374/why-differentiate-bss-and-common-section –  Sep 01 '20 at 02:22