[PATCH] D33673: [Object/RelocVisitor] - Add support for R_X86_64_DTPOFF32 relocation.

[Rafael Avila de Espindola via llvm-commits]

George Rimar <grimar at accesssoftek.com> writes:

>>BTW, these sections are also written out by lld, no? It seems odd to
>>relocate them twice. I wonder if we can do better.
>
> I had a patch to build .gdb_index after LLD resolves all relocations on its side (D31424). It had 2 limitations:
> 1) (secondary) First of all I had to find .gdb_index size early (because we do relocations in writeTo, so at that moment I had to know
> the size). To do that I used DWARF parsers twice, first time I provided unrelocated sections and told him them are relocated.
> That worked fast and allowed me to take **amount** of different entries quickly. I used that amount to calculate section size.
> Worked fine for everything except address ranges. 
> We can't find amount of ranges until relocations are applied or proccessed somehow because [0x0, 0x0] range is a terminator.
> And parser fails to return them. So I had to do rough estimate here. 
> On second call I feed parser with actually relocated sections and got real values for building index.

Yes, cases where we need to find the size first are annoying. If we were
to not use mmap for output it should be possible: first write the alloc
part, now we can compute anything we want about the non-alloc part
(including debug info) and write it.

That is a pretty big change and it is not clear if it is worth it.

One interesting thing to note is that we don't actually want to relocate
these sections. What we want is to read the relocation, in a similar
way that lld does on the scanRelocs. For example, when reading
DW_AT_low_pc, we don't want the final value, we want what it points to
(section and offset). With elf_rela we can find that with no knowledge about
relocations and with elf_rel we only need to know how to read the
implicit addend.

Cheers,
Rafael