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

[George Rimar via llvm-commits]

>George Rimar <grimar at accesssoftek.com> writes:
>> Because DWARFContextInMemory currently prints a error, but continues parsing object in the case
>> when something wrong with proccessing of relocations:
>>
>>       object::RelocVisitor V(Obj, L ? L->getTlsSize() : 0);
>>       uint64_t Val = V.visit(Reloc.getType(), Reloc, SymInfoOrErr->Address);
>>       if (V.error()) {
>>         SmallString<32> Name;
>>         Reloc.getTypeName(Name);
>>         errs() << "error: failed to compute relocation: " << Name << "\n";
>>         continue;
>>       }
>>
>> So do you mean we should just teach RelocVisitor to resolve it just to something, like zero or symbol value,
>> just to stop emiting error ?
>
>No. We should propagate the error and fail the link.
>
>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.

2) (primary) This is the reason why I stopped working on this idea: building .gdb_index on non-relocated inputs, like now,
gives a chance to implement multithreaded case easily. Just a few changes required for D33552 to switch from
"for" to "parralel_for". And that keeps whole implementation simple. May be applying some relocations twice is not so bad
in compare with more complicated implementation ? (I can't imagine simple one now).

>
>Cheers,
>Rafael

George.