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

[Rui Ueyama via llvm-dev]

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.

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.

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.

4. Last but not least, any code that is not obvious needs explanation in
comment, so that first-time readers who have basic knowledge on ELF can
read and understand the code. Even if code is very simple, comment may be
needed, because readers may want to know not only what is to be done but
also why we want to do that for what.

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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160121/8dc8b268/attachment.html>