[RFC] Libstdc++ dll conformance solution. [Re: Cygwin 1.7 release (was Re: ??? The library or libraries will be delivered[...])]

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

Dave Korn wrote:
> Corinna Vinschen wrote:

>> That's still a sore point.  Dave, is there any chance we can switch
>> to gcc-4 as standard compiler for Cygwin 1.7 within the next 4 weeks?
> 
>   Yep, there is.  What we need is
> 
> 1.  Solution to the libstdc++ DLL operator new/delete function replacement
> problem.
> 2.  New release of binutils from head.
> 
>   #2 may be dependent on #1, depending on the solution adopted, and I have
> decided over the past week or so to take a new tack which I will raise for
> discussion over on -developers in just a minute, but I think it should be
> acceptable and can be done quicker than my original plan.

  So, to enlarge.  Rather than implement full ELF-style dynamic runtime
resolution, or even partial-for-weak-symbols-only ELF-style dynamic blah blah
blah, I reconsidered a suggestion that I think originally came from Brian to
adapt and extend the existing malloc wrappers.

  If I did it this way, I would add strong exported definitions of the
operators to the Cygwin DLL itself, and compile the definitions in libstdc++
DLL as weak, but the definitions in static libstdc++ as strong.  Any
application or DLL being linked shared, including libstdc++ itself, would
import the definitions from the Cygwin DLL.  Any application being linked
statically would pull in the strong definitions.  We then would do the usual
trickery in a statically linked CRT object to record what function got found
at final link time, and can redirect to a static one in the app, or
dynamically look up the weak definitions in the DLL.

  I would need to take some care to ensure not to interpose the existing
operator new/delete implementations used internally within the DLL from
cxx.cc, because I don't think we want to let the user write their own
allocater for "kernel structures".  I will also need to take care that
existing programs don't need recompiling, because I'm going to need to change
the user_data struct; I'll take a single reserved member and use it to point
to an optional struct that contains all the new function pointers.

  I will also not do anything that would require the Cygwin DLL to sprout
dependencies on either the libstdc++ or libgcc_s DLLs, but I would want to
remove "-nostdinc++" from the compilations of the wrapper-related files so
that they could see the real include files and get definitions they need from
the std:: namespace.

  Timescales: I have one outstanding patch against binutils at the moment:

      http://sourceware.org/ml/binutils/2009-05/msg00542.html

  Getting this patch installed would be vital before doing a new distro
release of binutils if we follow this plan.  There are well-founded concerns
from the MinGW guys about the interoperability of anything we change in this
area with MS tools, but I think I've done enough diligence to convince even
the skeptical that the change is correct.  I haven't heard back from Aaron or
Danny yet.  We can't wait forever but I'd really like them on board, so I'll
ping them offlist and see if either has time to look at it in the next week;
if not I'll probably go ahead with it and offer to help fix any problems it
gives them after the fact.

  Also, I'm now booked up until the other side of the weekend with
volunteering for our local festival (http://www.strawberry-fair.org.uk/), so
none of this will start until next week.

  I already got far enough into a "do one first to throw away" hacky first
draft of patching the DLL to convince myself that this approach would be
possible, reasonable, and fairly speedy.  So I could usefully be writing that
while giving the MinGW team a few more days to respond to the binutils patch,
and by the end of the week I should have a working solution and a rebuilt
compiler to match and be able to give it some testing.  At that point I'd want
to commit the weak changes and we could pull the switch on a new binutils
release; then I'd do an updated compiler package to follow ASAP after that.

  I think this is a practical solution for the problem domain, punt though it
does on the more ambitious goals.  But, life is short, and gcc stage1 even
shorter, and I'd like to get all this working upstream too, so I think it's a
better option.  I think it's probably safer than the fuller design, as it
largely just builds on a well understood technique that we've been using for a
long time now.

  So, would this design be acceptable to everyone?

    cheers,
      DaveK