This is the mail archive of the binutils@sourceware.org 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] PE-COFF: Fix false positives in auto-export per-library filtering


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


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