[REVISED] Re: [PATCH] PE-COFF: Fix false positives in auto-export per-library filtering

["Dave Korn" <dave dot korn dot cygwin at googlemail dot com>]

Christopher Faylor wrote:
> On Mon, Dec 29, 2008 at 02:53:34PM +0000, Dave Korn wrote:

>> But the leading substring match doesn't check that there's any kind of
>> extension at all immediately after the matching leading part, so it can
>> be fooled by names that begin the same as a system library.  This
>> happens, for example, during a build of GCC, when you're compiling
>> libstdc++ as a DLL: the symbols pulled in from the libtool-generated
>> libsupc++convenience.a trigger a false match against a filter looking for
>>  one of libsupc++{.a,.dll.a} and the result is that none of the symbols
>> from libsupc++ gets exported from the final DLL, meaning applications
>> can't link against them.
>>
>> Seems to me the simplest fix is just to extend the leading parts in the
>> list of filtered libraries so they check there's a period, implying that
>>  there's probably a file extension following.  (Yes, this could still be
>>  fooled by a name like 'libsupc++.convenience.a').

  I looked into the history of this.  The list originally used periods when
it was first added, but as a result of the thread at [1], they were removed
(by the patch at [2]) in order to widen the detection to match "libstdc++-2.a"
which was then shipping with the now-withdrawn gcc-2 package.

  I have modified my original patch so it now allows version suffixes as well
as periods after the leading match; otherwise it would have just amounted to
reverting the earlier patch.

> Wouldn't it be better to generate a real .def file for complicated
> libraries like lib*++ rather than relying on auto-export?

  Probably so in the long run, but it's a whole load more hackery for an
incremental improvement. As Aaron observed[3] with his patch for shared libgcj
et al., we'd need a way of converting an ELF version script to a DEF file;
that works ok for shared libgcc, using mkmap-flat.awk to generate a flat map
file from libgcc-std.ver, but only because libgcc-std.ver specifies each and
every export explicitly, and doesn't use any of the advanced version script
features like globbing and language-specific linkage-demangling. The more
complex libs make use of these features so there's a dependency on solving
that problem before it could work.

  In the meantime, the intent of the patch at [2] was clearly to "Don't be
fooled by version suffixes", but the implementation made the test broader even
than that and also allowed things that weren't version strings, such as the
suffix "convenience".  The attached patch refines the overly-broad test to
more closely match the original requirements, so it's a reasonable fix for
correctness regardless whether GCC continues to rely on auto-export or not in
the future.

  Once I've got DLL-ized GCC4 out the door, I could come back and look at
making PE-ld able to parse ELF version scripts and generate DEF-files from them.

  So, here's a ChangeLog entry for the revised patch (attached).

	* pe-dll.c (autofilter_liblist):  Add entry for shared libgcc.
	(libnamencmp):  New function.
	(auto_export):  Use it in place of strncmp when filtering libraries.


    cheers,
      DaveK
-- 
[1] - http://sourceware.org/ml/cygwin/2002-11/msg00452.html
[2] - http://sourceware.org/ml/binutils/2002-11/msg00317.html
[3] - http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01797.html

Attachment: ld-autoexport-lib-autofilter-fix-patch-take-2.diff
Description: Binary data