This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: [RFC] Cygwin libstdc++ plan (operator new/delete replacement)
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