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? 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?> 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/f7d3aa3e/attachment.html>
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.> >> 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. - 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.
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>