[llvm-dev] Need to refactor relocation handlers in ELF LLD

[Rafael Espíndola via llvm-dev]

>> I would like to leave this as a last resort. Putting things that don't
>> take part in symbol resolution into the symbol resolution is confusing
>> IMHO.
>
>
> I don't think so, as the symbol plays a major role not only in symbol
resolution but also in relocation application. It is easier to model that
all relocations point to symbols. That is true in ELF so that's a direct
modeling of the ELF structure. Let me try to experiment -- we can abandon
the idea if it becomes clear that that doesn't worth.

Sure. At this point we should try a few experiments and see what works.
.

>
>> > My bar for readability may be a little bit high, but I strongly
believe that
>> > that will eventually increase overall productivity. I really need help
from
>> > LLD developers to keep it readable and hackable. I'd greatly
appreciate any
>> > patch to reduce complexity. Thanks!
>>
>> Thanks a lot for the work at making lld easier to understand.
>>
>> I was away from coding and catching up on code review, but I agree
>> that this is important and will try to improve things a bit in here
>> before going back to code review (and then LTO).
>>
>> What I will probably try first is reordering output so that we don't
>> need to compute the size upfront. That should give us quite a bit of
>> flexibility in refactoring anything else. I don't know if it will be
>> too costly, but I will report on anything I find.
>
>
> I don't know if computing the size upfront increased complexity. Was it?

It is. That is what requires that in two points in the code we come up the
same answer as to whether a relocation is optimized for example.

If we didn't need to know that we could centralize the knowledge: write,
regular sections, relocate, write dynamic relocations.

Changing it is an experiment both in complexity and performance, but I
should hopefully have a proof of concept tomorrow.

Cheers,
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160121/4797abf6/attachment.html>