[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