[LLVMdev] Changing the design of GlobalAliases to represent what is actually possible in object files.

Eric Christopher echristo at gmail.com
Fri May 23 15:15:08 PDT 2014


On Fri, May 23, 2014 at 3:06 PM, Rafael Avila de Espindola
<rafael.espindola at gmail.com> wrote:
>
>
> Sent from my iPhone
>
>> On May 23, 2014, at 17:51, Eric Christopher <echristo at gmail.com> wrote:
>>
>> I'm not there yet, but at some point I'm going to need the notion of a
>> global callable function like symbol that's resolved at runtime. I've
>> not given it much thought but I may need a new callable entity here
>> (this is for the gnu ifunc stuff).
>>
>> Don't even know if this fits into the discussion, but since we were
>> talking about weird symbols...
>>
>
> It is a symbol or a value that is loaded? If it is an symbol, what does it point to? That is, what is the value that shows up in the .o?

Relocation resolved at compile time to one of N symbols that will be
the call that's made.

-eric

>
>
>> -eric
>>
>>> On Fri, May 23, 2014 at 1:26 PM, Reid Kleckner <rnk at google.com> wrote:
>>> On Thu, May 22, 2014 at 7:14 PM, Rafael Espíndola
>>> <rafael.espindola at gmail.com> wrote:
>>>>
>>>>> For example, it would not be possible to define an absolute symbol to be
>>>>> the offset between two symbols.  In some restricted circumstances —
>>>>> if both symbols are global variables in the same section and defined
>>>>> in the same translation unit — this could be worked around.
>>>>>
>>>>> But I’ll gladly admit that I don’t have a use case in mind for that
>>>>> feature.
>>>>> Absolute symbols are useful, and storing offsets between symbols into
>>>>> global memory is useful, but I don’t know why you’d combine them.
>>>>
>>>> That is funny. I, on the other hand, think that this is the best
>>>> argument I have seen for keeping aliases pointing to ConstantExpr so
>>>> far.
>>>
>>>
>>> IMO if we want to support defining symbols at absolute addresses, we should
>>> add a separate construct for this.  So far everyone has gotten by with
>>> linker flags and scripts, though.
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>




More information about the llvm-dev mailing list