[patch] ld: PE: comprehensive auto-filtering for DLL-exportable symbols

[Christopher Faylor]

On Sun, Apr 29, 2001 at 03:56:57PM +0300, Paul Sokolovsky wrote:
>  This is a followup to recent thread concerning how "auto-export"
>works for PE DLLs. To remind, ld has "auto-export" feature which
>allows DLLs built from a set of object files automagically export all
>symbols - just the same as standard *nix shared libraries work -
>instead of using win32 idiosyncrasy of listing each symbols in .def
>file or marking it with __declspec(dllexport) in the source code.
>
>   Unfortunately, auto-export used to work not very well due to
>different shortcoming, one of which was recently raised on this list:
>it is too much being exported with it. This is not aesthetical, waste
>space in export section, and sometimes even impedes linking against
>such library due to duplicate symbols. I addressed this problem
>several months ago, and since that binutils with changes proposed
>were available for testing at http://sourceforge.net/projects/mingw/ .
>
>   Attached patch got its shape in several iterations, as I was
>understanding that adequate filtering was not possible with just
>pattern filtering of symbol names. So, it uses several heuristics to
>achieve adequate effect:
>
>1. Pattern filtering of symbol names (leave out bunch of startup
>   symbols, import thunks, C++ internal stuff like __rtti_*, etc.)
>2. Pattern filtering plus querying symbol table (do not re-export
>   symbols which were imported from other DLL, i.e. exist only as
>   the thunks in the object being produced)
>3. Contextual filtering by containing library name (no need to export
>   anything coming from predefined libraries like libgcc or
>   libstdc++).
>
>   For more discussion and effects of this patch, see
> http://cygwin.com/ml/cygwin/2000-11/msg00242.html . Hope this
>description was comprehensive enough to support the patch.

You've got my support, Paul.  Your patch sounds like a good thing to
me.  I'm tempted to apply it to a cygwin binutils release right now,
in fact.

cgf