[whopr] plugin interface design

[Chris Lattner]

On Jun 5, 2008, at 10:38 AM, Ian Lance Taylor wrote:
>>> Sure.  But here's the thing: the gcc LTO approach involves having a
>>> regular object with a regular symbol table, and the IR is embedded  
>>> in
>>> the object.  In other words, we do know the symbol version
>>> information: it's in the symbol table of the object.
>>
>> Wow, that seems incredibly limiting.  This means that your LTO either
>> has to:
>>
>> 1) treat the object header as part of the IR, or
>> 2) avoid making any changes that would affect exported symbols
>>
>> Is that right?  Why doesn't the "LTO reader" just read the symbol  
>> info
>> from the ELF header and reflect it into the trees somehow?
>
> For example, earlier Nick suggested that LLVM will not inline a weak
> symbol.  With ELF it is actually OK to inline a weak symbol when
> generating an executable.  It is not OK when generating a shared
> library, unless -Bsymbolic was used on the linker command line.  We
> could represent these sorts of details directly in the compiler IR.
> But I don't see a big advantage to doing so.

Sure, IMO that information should be reflected in the IR.  As you  
know, I have a strong bias towards making the IR fully self contained  
and self describing.  You're right that this may not be absolutely  
required though.

> Incidentally, your choice 2 above doesn't follow.  The LTO compiler is
> going to pass a new object file(s) back to the linker.  It doesn't
> have to have the same set of exported symbols, except in cases where
> the linker has directed that some symbol must be available.

If you only have one IPO pass, it doesn't matter.  If you have two or  
more passes then the first pass needs some way to communicate the  
changes it made to the second and later passes.  Presumably you don't  
want to be hacking on the input object files, and the output object  
file doesn't exist yet.

-Chris