On 3/11/20 1:51 PM, Richard Biener wrote:
I'm not sure I understand the versioning, we should aim at something where an updated plugin can talk to old and new ld and where a new ld can also talk to an old plugin. That requires an arbitration which I don't see implemented?
So ld-new will set new callbacks tv_add_symbols_v2 and tv_get_symbols_v4, these contain ld_plugin_symbol_v2 with filled ::symbol_type. ld-new will check for he new API with LDPT_GET_SYMBOLS_V4, LDPT_ADD_SYMBOLS_V2 and will tv_add_symbols and tv_get_symbols callbacks. ld-old will use the old tv_add_symbols and tv_get_symbols callback. One another level of compatibility is the LTO bytecode, where new plugin should handle also old LTO bytecode. That's done with parsing of LTO bytecode version (lto_section).
Splitting an existing field isn't hackish IMHO. I guess even explicitely changing it to one short and two char fields would be OK.
Then I'm fine with that as well. Am I right that the split order will depend of the endianess?
Is there a comprehensive list of plugins out in the wild using the LD plugin API?
I know only about: $ ls /usr/lib/bfd-plugins liblto_plugin.so.0.0.0 LLVMgold.so and I know about Alexander Monakov (some dead code elimination plug-in).
Note we also have to bring in gold folks (not sure if lld also implements the same plugin API)
I don't see how can they be affected? Martin
