Re: [PATCH/RFC] Fix LD test FAIL: weak symbols on Cygwin

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

Aaron W. LaFramboise wrote:

> A lot of people feel that PECOFF should be extended with an ELF-like
> weak symbol,

 *puts hand up* :)

> which presumably would be called C_WEAKEXT.   The C_NT_WEAK
> symbols presently implemented by .weak in gas have some special features
> that make them behave more alike to to ELF weak symbols than implemented
> in Microsoft's tools, without breaking standard conformance.

  Is this the allowing-the-default-to-also-be-undefined extension you're
referring to here?

> (The
> effect of this is that weak symbols generated by gas will work just fine
> with MS LINK.)

  I looked at the testcase in
        http://sourceware.org/bugzilla/show_bug.cgi?id=9687
and it seems to me from that, that the only usage model which currently works
is a weak reference along with a weak/default definition in the same .o file
and optional strong definitions in other .o files at final link time.  What
does not work in that case is only having weak definitions at final link time.

- Am I correct in this analysis?
- Does it imply that the GNU extension is no longer working as it is supposed to?
- If we changed the characteristic to IMAGE_WEAK_EXTERN_SEARCH_ALIAS wouldn't
that allow this case to work without affecting the above usage?  In fact,
shouldn't it already be that way anyway?  Or perhaps only when the gnu
extension is not in use?

Danny Smith wrote:

> No , I haven't done this (not on purpose, anyway) nor am I keen on
> such extensions.
> Like you I would like to see weak externals implemented as close as
> possible to PE-COFF spec.

  I would like to extend PE binutils to support much more ELF-like weak
symbols, for use in Cygwin.  I will *of course* not break any backward
compatibility and ensure that whatever I do is a purely option extension.  So,
the simplest way to do that would seem to be as Aaron suggests to add support
for C_WEAKEXT and leave the existing C_NT_WEAK support alone, yes?  In
principle we could just add an entirely new ".elfweak" pseudo-op in GAS and
teach GCC when to generate that directive instead of plain ".weak", no?

>   'Vague definitions'  should be implemented
> using link-once COMDAT sections.

  I don't believe this can solve the problem of e.g. interposing a
user-defined operator new in the path of internal calls from stl functions
within libstdc++ DLL, can it?

> The problem is that people hear that win32 targets SUPPORT_WEAK and
> automatically assume that now it can do everything that ELF .weak
> does.  That would be nice, as a GNU extension, but I for one would
> like my object code to be understood by  MS as well as  GNU tools.

  Well, I heard that win32 has some kind of weak support, and set out to see
what it did and how it compares to ELF weak support.  As I said, I'll make
sure any extension is just that, an optional extension, but as it's going to
do stuff that MS just can't do, I don't think there's any way MS tools can be
made to understand (or even just cope with) it when the extension is in play.
 The plans I have necessitate runtime support, for starters (for which I was
proposing to press Kai's v2 runtime-pseudo-relocs into service).

  I think it should be relatively straightforward for Cygwin (and MinGW if
desired) to have real ELF-like weaks that can even be unresolved at
application startup and resolved during runtime by dlopen()ing a library that
provides them, without in any way harming interoperability with MSVC tools
when only standard features are in use.  Looks like now would be a good time
for me to start drafting a semi-formal design and implementation plan, eh?

    cheers,
      DaveK