[whopr] Design/implementation alternatives for the driver and WPA

[Chris Lattner]

On Jun 4, 2008, at 12:27 AM, Rafael Espindola wrote:

>> Is there a specific reason you don't use the LLVM LTO interface?   
>> It seems
>> to be roughly the same as your proposed interface:
>>
>> a) it has a simple C interface like your proposed one
>> b) it is already implemented in one system linker (Apple's), so GCC  
>> would
>> just provide its own linker plugin and it would work on apple  
>> platforms
>> c) it is richer than your interface
>> d) it is battle tested, and exists today
>> e) it is completely independent of llvm (by design)
>> f) it is fully documented: http://llvm.org/docs/LinkTimeOptimization.html
>>
>> Is there something specific you don't like about the LLVM interface?
>
>
> We are still discussing how we are going to implement, so the API is
> still not final. Some things that have been pointed out:

Hey Rafael!

> *) Plugins could have other uses and the naming used on the LLVM LTO
> interface is LTO specific.

The LLVM interface uses an lto_ prefix.  This interface is used by nm/ 
ar/etc as well as the linker.  Is there something specific about lto_  
that is bad?
http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm-c/lto.h?revision=HEAD&view=markup

> *) We have a normal symbol table on the .o files. It is not clear if
> we should assume that it will always be the case. If so, we don't need
> the API part that handles that.

This seems like a pretty minor point, but it would be easy to either:

1) make this an optional interface
2) make the plugin implement the symtab interfaces, but query the ELF  
symbol table instead of the LTO symbol table if possible.

> *) How do you handle the case of multiple symbols with the same name
> (say a weak and a strong one)? lto_codegen_add_must_preserve_symbol
> has a char* argument. How does it know which symbol we are talking
> about?

The lto_symbol_attributes enum specifies linkage.

> *) To save memory, one option is to have the plugin exec WPA and WPA
> exec the linker again with the new objects. In this case the api
> should be a bit different.

That's an interesting idea, but it is very unclear to me whether it  
would save a significant amount of memory.  Operating system VM  
systems are pretty good at paging out data that isn't used (e.g.  
the .o files the linker loaded into memory that exist when WPA is  
going on).

-Chris