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

[Rui Ueyama via llvm-dev]

On Thu, Jan 21, 2016 at 11:59 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> >> 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.
>
I guess that you are trying to layout sections that have fixed size first
and then other sections that vary in size (such as GOT, string tables,
etc.) after them.

But users can enforce some ordering using linker script. Is it going to be
compatible with that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160121/2f95056f/attachment.html>