[LLVMdev] Changing the design of GlobalAliases to represent what is actually possible in object files.
Rafael Avila de Espindola
rafael.espindola at gmail.com
Fri May 23 15:06:07 PDT 2014
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?
> -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