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

[Rafael Espíndola via llvm-dev]

On 21 January 2016 at 04:11, Rui Ueyama <ruiu at google.com> wrote:
> We have fairly large and complex code to handle relocations in Writer.cpp,
> Target.cpp, OutputSections.cpp and InputSections.cpp. They started with
> simple code, but because each patch added a small piece of code to the
> existing one, it is becoming out of control now. For example, we have lots
> of entangled boolean flags in the functions that interfere with each other
> in an obscure fashion. Even I don't understand all these interactions.
>
> We need to clean this up to get it back to be manageable. The code in
> SymbolTable.cpp is for example pretty much readable and in my opinion
> beautiful. I want the relocation handlers to be as readable as that is.
>
> I think there are a few things we can to do to fix the problem.
>
> 1. I'd like everybody to not add any more complexity to the relocation
> handler until we clean this up because as we add more code, it gets harder
> to refactor. Any patch to reduce complexity is welcome.

I agree. A short moratorium while we experiment with refactoring
sounds reasonable.

> 2. The fact that we don't create SymbolBodies for local symbols is one of
> the major factors to contribute that complexity. I experimented on creating
> them, and the performance penalty seemed to be within a few percent, so
> that's a good trade-off. I'll try that. We can offset that degradation with
> optimizations in other places.

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.

> 3. We probably want to separate relocation relaxation from relocation
> application. Currently it is a unified pass, but theoretically we can split
> it up into two, so that we do relaxation and then apply remaining
> relocations.

I agree with this one. A similar comment applies for deciding if we
need a dynamic relocation and actually creating it.


> 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.

Cheers,
Rafael