This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: new linker option for shared library COMDAT optimization

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]