This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] PE-COFF: Fix false positives in auto-export per-library filtering
- From: Christopher Faylor <cgf-use-the-mailinglist-please at sourceware dot org>
- To: binutils at sourceware dot org, Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- Date: Mon, 29 Dec 2008 14:51:00 -0500
- Subject: Re: [PATCH] PE-COFF: Fix false positives in auto-export per-library filtering
- References: <2ca21dcc0812290653q73fa23fenb9b9dea97dbb5cae@mail.gmail.com>
On Mon, Dec 29, 2008 at 02:53:34PM +0000, Dave Korn wrote:
> Afternoon all,
>
> The attached patch fixes a little hiccup in the auto-export feature of
>PE-COFF ld when building DLLs. If you build a DLL without supplying an
>explicit list of exports (in a .DEF file), ld will automatically export all
>the public symbols pulled into the final link.
>
> However, if you're linking the DLL statically against system DLLs or
>runtime crtbegin/end objects, re-exporting those symbols would not be what
>you want. To that end, ld filters out symbols belonging to known system
>libraries when it's generating the list of auto-exports.
>
> That's all well and good, but the code that matches against the list of
>libraries to filter only uses a leading substring match. That's ok too,
>because we could be linking against a *.a static archive or a *.dll.a import
>library, and either way we don't want to re-export the symbols from it.
>
> 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'). While I was at it, I also
>added a new entry for the shared version of libgcc that we're shipping with
>Cygwin these days.
>
>
>2009-12-29 Dave Korn <dave.korn.cygwin@gmail.com>
>
> * pe-dll.c (autofilter_liblist): Add periods to avoid false-positive
> matches on leading substring of library name, and add shared libgcc.
>
>
> Ok?
Wouldn't it be better to generate a real .def file for complicated libraries
like lib*++ rather than relying on auto-export?
cgf