[LLVMdev] LLD improvement plan

[Rui Ueyama]

On Fri, May 1, 2015 at 2:10 PM, Michael Spencer <bigcheesegs at gmail.com>
wrote:

> On Fri, May 1, 2015 at 1:42 PM, Rui Ueyama <ruiu at google.com> wrote:
> > On Fri, May 1, 2015 at 1:32 PM, Michael Spencer <bigcheesegs at gmail.com>
> > wrote:
> >>
> >> On Fri, May 1, 2015 at 12:31 PM, Rui Ueyama <ruiu at google.com> wrote:
> >> > Caveat Why not define a section as an atom and keep using the atom
> >> > model? If
> >> > we do this, we would have to allow atoms to have more than one name.
> >> > Each
> >> > name would have an offset in the atom (to represent symbols whose
> offset
> >> > from the section start is not zero). But still we need to copy section
> >> > attributes to each atom. The resulting model no longer looks like the
> >> > atom
> >> > model, but a mix of the atom model and the section model, and that
> comes
> >> > with the cost of both designs. I think it’s too complicated.
> >>
> >> Rafael and I have been discussing this change recently. It makes atoms
> >> actually atomic, and also splits out symbols, which has been needed.
> >> The main reason I like this over each target having its own model is
> >> because it gives us a common textual representation to write tests
> >> with.
> >
> >
> > If you allow multiple symbols in one atom, is the new definition of atom
> > different from section? If so, in what way?
>
> It's pretty much the same. I read what you said as having a different
> section representation for each target.


No, the class definition for the section for PE/COFF and ELF would be the
same. Also if we can use that for Mach-O, we should use that too. And if
it's the same as section, I'd call it section rather than atom.


>
> >
> >> As for symbol resolution. It seems the actual problem is name lookup,
> >> not the core resolver semantics.
> >
> >
> > What's the difference between name lookup and the core resolver
> semantics?
> >
>
> Name lookup would be how it finds what symbols to consider for
> resolving. The core resolver semantics is mostly
> SymbolTable::addByName.


Yeah, how we resolve (conflicting) symbols is mostly the same, and the
difference is in how we find files defining undefined symbols.


> - Michael Spencer
>
> >>
> >> I'd rather not end up with basically 3 separate linkers in lld.
> >
> >
> > I basically agree. However, if you take a look at the code of the PE/COFF
> > port, you'll find something weird here and there.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150501/f10a11e6/attachment.html>