> Hey Rafael! Hello! >> *) 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
This is a minor comment. All the design is done based on what LTO needs, but since it could be possible to use plugins for other things the proposed API uses a generic prefix. >> *) 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. Sure. There is just the issue of the many function calls. Not sure how expensive this is. Maybe have the plugin construct a symbol table with everything that is on the file? >> *) 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. That allows the plugin to pass information to the linker. But if there are two symbols named "foo". How can the linker instruct the plugin to generate code for only one? The function that LLVM uses is lto_codegen_add_must_preserve_symbol(lto_code_gen_t, const char*) right? Maybe adding a lto_symbol_attributes argument would be enough, but having an abstract object is probably better. >> *) 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). Sure. Again, the document is in a early stage, and we listed most of the options. Restarting the linker is not a very popular option, but might be worth trying. > -Chris > Cheers, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
