<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 1, 2015 at 2:10 PM, Michael Spencer <span dir="ltr"><<a href="mailto:bigcheesegs@gmail.com" target="_blank">bigcheesegs@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 Fri, May 1, 2015 at 1:42 PM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> On Fri, May 1, 2015 at 1:32 PM, Michael Spencer <<a href="mailto:bigcheesegs@gmail.com">bigcheesegs@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Fri, May 1, 2015 at 12:31 PM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
>> > Caveat Why not define a section as an atom and keep using the atom<br>
>> > model? If<br>
>> > we do this, we would have to allow atoms to have more than one name.<br>
>> > Each<br>
>> > name would have an offset in the atom (to represent symbols whose offset<br>
>> > from the section start is not zero). But still we need to copy section<br>
>> > attributes to each atom. The resulting model no longer looks like the<br>
>> > atom<br>
>> > model, but a mix of the atom model and the section model, and that comes<br>
>> > with the cost of both designs. I think it’s too complicated.<br>
>><br>
>> Rafael and I have been discussing this change recently. It makes atoms<br>
>> actually atomic, and also splits out symbols, which has been needed.<br>
>> The main reason I like this over each target having its own model is<br>
>> because it gives us a common textual representation to write tests<br>
>> with.<br>
><br>
><br>
> If you allow multiple symbols in one atom, is the new definition of atom<br>
> different from section? If so, in what way?<br>
<br>
</span>It's pretty much the same. I read what you said as having a different<br>
section representation for each target.</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
><br>
>> As for symbol resolution. It seems the actual problem is name lookup,<br>
>> not the core resolver semantics.<br>
><br>
><br>
> What's the difference between name lookup and the core resolver semantics?<br>
><br>
<br>
</span>Name lookup would be how it finds what symbols to consider for<br>
resolving. The core resolver semantics is mostly<br>
SymbolTable::addByName.</blockquote><div><br></div><div>Yeah, how we resolve (conflicting) symbols is mostly the same, and the difference is in how we find files defining undefined symbols.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
- Michael Spencer<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
>><br>
>> I'd rather not end up with basically 3 separate linkers in lld.<br>
><br>
><br>
> I basically agree. However, if you take a look at the code of the PE/COFF<br>
> port, you'll find something weird here and there.<br>
</div></div></blockquote></div><br></div></div>