[LLVMdev] [lld] ELF weak aliases
shankare at codeaurora.org
shankare at codeaurora.org
Wed Jan 9 06:07:49 PST 2013
> On Tue, Jan 8, 2013 at 8:56 PM, <shankare at codeaurora.org> wrote:
>> Hi Michael,
>>
>> Does ELF support aliasing ?
>>
>> How is the relationship captured in ELF symbol table, that one symbol is
>> a
>> alias of another symbol ?
>
> It is not explicitly captured. It's an implicit relationship due to
> the symbols having the same address.
Got it.
>
>>
>>> Note that __stdout_used is the last symbol in the .rodata section.
>>> This means that the reader assigns the data (16 bytes of 0) to
>>> __stdout_used. Because dummy_file and the other __stdx_used symbols
>>> come before it, they end up in the right place in the final file.
>>
>> Did you change the Reader too ?
>
> No. I just made another symbol to steal the actual content.
We could change the Reader so that if the symbol is the last symbol in the
section and the symbol is weak, treat the size of the symbol differently.
>
>>
>> The Reader doesnot allocate any space for __stdout_used. The size of the
>> current symbol = (value of next symbol - current symbol). In this case
>> its
>> zero.
>
> __stdout_used is the last symbol at that address, so it gets the data.
> The hack was to make __stdout_used not get the data.
Got it. Thanks for explainining things.
>
>>
>>>
>>> This works great until another object file provides a definition of
>>> __stdout_used. The weak definition of it gets totally removed, meaning
>>> so does the content for the other __stdx_used symbols.
>>
>> When the other object provides a definition for __stdout_used, the atom
>> gets the property of the other object which defines the atom isnt it,
>> and
>> so as the ordinal too riht ?
>>
>> Couldnt follow how did the others move ?
>
> I'm not quite sure what you mean here.
Sorry for not making it clear. I was not sure how did the content of the
other symbols change when another object file provided a definition of
__stdout_used ?
Thanks
Shankar Easwaran
More information about the llvm-dev
mailing list