PATCH: new linker option for shared library COMDAT optimization
Sandra Loosemore
sandra@codesourcery.com
Wed Feb 29 18:23:00 GMT 2012
More information about the Binutils mailing list
Wed Feb 29 18:23:00 GMT 2012
- Previous message (by thread): PATCH: new linker option for shared library COMDAT optimization
- Next message (by thread): PATCH: new linker option for shared library COMDAT optimization
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 02/20/2012 04:40 PM, Alan Modra wrote: > On Fri, Feb 17, 2012 at 11:41:03AM -0700, Sandra Loosemore wrote: >> The slight wrinkle in this scheme is that the ELF specification >> defines COMDAT groups as an attribute of relocatable files only, not >> shared objects. So we cannot say definitely that a shared object >> provides a named COMDAT group. The expedient hack I've adopted is >> to consider that a shared library provides a COMDAT group if it >> provides weak definitions for all symbols defined in sections that >> make up the group. > > I wondered how robust this will prove to be. > [snip] > That's rather a lot of missing symbols. I think for this to work you > need another linker option to export all global symbols defined in > comdat sections. Hmmmm, it seems to me that this is a separate issue. Maybe it even makes more sense to implement it as a compiler option instead, consistently with -fvisibility, -fvisibility-inlines-hidden, and #pragma GCC visibility. Between those options and linker EXPORT lists, it seems to me that it is certainly already possible to build shared libraries that export the necessary symbols, although it may take some extra work to do so. Would it suffice for the purposes of the current patch to add a bit to the documentation for --shared-comdat explaining that it requires that the comdat symbols have default (exported) visibility in the shared library, and that this may require changes to how the library is built? > Then, given that you will need to build shared > libraries differently, it would be a much better idea to mark them as > supporting shared-comdat, perhaps by exporting each comdat signature > symbol. If you did that, you could probably dispense with all the > code you've written to match symbols.. I previously considered keying off the comdat signature symbol only, but thought that it might be too easily fooled. Perhaps as a less-strict version of what I have now, I could require that the shared library provide definitions for only the comdat symbols that are referenced, instead of all of them? I think that is consistent with what building with -frepo would do. -Sandra
- Previous message (by thread): PATCH: new linker option for shared library COMDAT optimization
- Next message (by thread): PATCH: new linker option for shared library COMDAT optimization
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list