> > >>> @Honza/Richi: Do you have any opinion about that? > > > > > > I guess we indeed want to get as close to non-LTO nm behaviour as > > > possible. So we want to support them and perhaps think of .symtab > > > section file format that can be made backward compatible (such as having > > > attribute string for symbols where we can add new info in future in a > > > way that old plugins will still get info they want). > > > > I like the idea. But it's probably next stage1 material. Or can you prepare > > a patch? > > I think what's important is that the LTO plugin needs to understand > the old and the new version since there's only one for auto-loading. > > The other missing feature of the linker plugin API is file claiming > which should be a on a section basis instead - but that's a different > part of the API and not related to symbol tables. Enhancing that > part of the API would allow to elide the LTO debug copying ...
Thinking of it, it seems to me that we do not need to break compatibility with existing plugins. We could keep existing .symtab section the way it is implemented right now and add additional data to new .symtab_ext section so existing plugins will work as expeted. We could tag symtab_ext by a version string and keep adding extensions of extensions in the future being compatible with old plugins. Indeed that would help situation user already has distro provided plugin in the search path but compiles its own gcc10. Honza
