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


On Oct  2 01:54, Christopher Faylor wrote:
> 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.

ACK.  If the current code for cxx_malloc and friends is right (apart
from the kludge to get broken DLLs working), the right solution is to
fix the broken DLLs built against the broken test Cygwin DLL, rather
than adding more kludges to support them indefinitely.  It would be
different if this had been official Cygwin releases, but fortunately
these were just betas.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


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