<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 21, 2016 at 6:10 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 21 January 2016 at 04:11, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> We have fairly large and complex code to handle relocations in Writer.cpp,<br>
> Target.cpp, OutputSections.cpp and InputSections.cpp. They started with<br>
> simple code, but because each patch added a small piece of code to the<br>
> existing one, it is becoming out of control now. For example, we have lots<br>
> of entangled boolean flags in the functions that interfere with each other<br>
> in an obscure fashion. Even I don't understand all these interactions.<br>
><br>
> We need to clean this up to get it back to be manageable. The code in<br>
> SymbolTable.cpp is for example pretty much readable and in my opinion<br>
> beautiful. I want the relocation handlers to be as readable as that is.<br>
><br>
> I think there are a few things we can to do to fix the problem.<br>
><br>
> 1. I'd like everybody to not add any more complexity to the relocation<br>
> handler until we clean this up because as we add more code, it gets harder<br>
> to refactor. Any patch to reduce complexity is welcome.<br>
<br>
</span>I agree. A short moratorium while we experiment with refactoring<br>
sounds reasonable.<br>
<span class=""><br>
> 2. The fact that we don't create SymbolBodies for local symbols is one of<br>
> the major factors to contribute that complexity. I experimented on creating<br>
> them, and the performance penalty seemed to be within a few percent, so<br>
> that's a good trade-off. I'll try that. We can offset that degradation with<br>
> optimizations in other places.<br>
<br>
</span>I would like to leave this as a last resort. Putting things that don't<br>
take part in symbol resolution into the symbol resolution is confusing<br>
IMHO.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> 3. We probably want to separate relocation relaxation from relocation<br>
> application. Currently it is a unified pass, but theoretically we can split<br>
> it up into two, so that we do relaxation and then apply remaining<br>
> relocations.<br>
<br>
</span>I agree with this one. A similar comment applies for deciding if we<br>
need a dynamic relocation and actually creating it.</blockquote><div><br></div><div>Good point. Looks like visiting relocations sequentially is pretty fast because they are continuous in memory, so I expect that the cost of iterating over them a few times is marginal.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> My bar for readability may be a little bit high, but I strongly believe that<br>
> that will eventually increase overall productivity. I really need help from<br>
> LLD developers to keep it readable and hackable. I'd greatly appreciate any<br>
> patch to reduce complexity. Thanks!<br>
<br>
</span>Thanks a lot for the work at making lld easier to understand.<br>
<br>
I was away from coding and catching up on code review, but I agree<br>
that this is important and will try to improve things a bit in here<br>
before going back to code review (and then LTO).<br>
<br>
What I will probably try first is reordering output so that we don't<br>
need to compute the size upfront. That should give us quite a bit of<br>
flexibility in refactoring anything else. I don't know if it will be<br>
too costly, but I will report on anything I find.<br>
</blockquote></div><br></div><div class="gmail_extra">I don't know if computing the size upfront increased complexity. Was it?</div></div>