[LLVMdev] LLD improvement plan
Michael Spencer
bigcheesegs at gmail.com
Fri May 1 14:10:51 PDT 2015
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.
More information about the llvm-dev
mailing list