[RFC] Cygwin libstdc++ plan (operator new/delete replacement)

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Fri Oct 2 05:54:00 GMT 2009


On Fri, Oct 02, 2009 at 06:52:39AM +0100, Dave Korn wrote:
>Christopher Faylor wrote:
>>I don't see how you can remove the cygwin_external call as long as
>>there are dlls out there which reset this field in cygwin_crt0.cc.  You
>>just need one problem dll and this causes all sorts of bad problems
>>when loading other dlls.
>
>  We do in fact need to worry about it, because if the dll is from the faulty
>zone 49-57 and redirects the malloc struct pointer to its own internal one,
>and then the exe is pre-malloc stuff altogether and clears forkee at startup,
>then by the time we get to your restore code we'll have lost sight of the fact
>that there were a bunch of non-default overrides where the pointer got
>redirected to altogether.  So I think what we need is for both dll_crt0_1 and
>dll_dllcrt0_1 to execute a bit of code that looks like
>
>  if (pointer is NULL)
>     reset it to default cxx malloc
>  else if (pointer doesn't point to default)
>     copy entries from new pointer value into default struct
>     and reset pointer to point to default.

No, this has to stop at some point.  The current workaround is adequate
and really should go away soon; maybe even for 1.7.1.  We're not going
to stand on our heads for a handful of dlls which might have been built
using beta code and might have overridden the cxx_malloc structure.  I
made that decision when I added this kludge.

I think that the X libraries are the main offenders and I know that
Yaakov is more than willing to rebuild them.

I will, for now, move the cxx_malloc setting into check_sanity_and_sync,
though.  It arguably should have gone there to begin with.

cgf



More information about the Cygwin-developers mailing list