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: [Fwd: dlopen regression in 1.7? (or is it just me?)]


On Wed, Aug 12, 2009 at 12:08:08PM -0400, Christopher Faylor wrote:
>On Wed, Aug 12, 2009 at 05:16:00PM +0200, Corinna Vinschen wrote:
>>On Aug 12 15:48, Dave Korn wrote:
>>> Corinna Vinschen wrote:
>>> > Of course, we could also kludge dlopen to workaround "broken" DLLs.
>>> > It could store the old cxx_malloc pointer before calling LoadLibrary and 
>>> > restore it afterwards.  This would allow us to stick with these DLLs.
>>> > 
>>> > I tested the below patch to dlopen.  It seems to work nicely for the
>>> > testcase sent by Peter.  Any drawbacks?
>>> 
>>>   The only slight drawback is it means that you can't have a malloc override in
>>> a dlopen'd library, because it restores the pointer without copying back the
>>> updated set of overrides from the library's internal struct that the pointer now
>>> points at.
>>> 
>>>   Of course that's good because it means you can't dlclose it and suddenly have
>>> operator new disappear, but it might be a nice feature.  To make it work, we'd
>>> need to maintain a stack of override entries, so that at dlclose time we could
>>> restore the previous set of overrides.  I'm just pondering if we can figure out
>>
>>A stack wouldn't help since the dlclose calls can be in arbitrary order.
>
>Right, but couldn't you store/restore this in the per-dll structure?

Which is already a linked list, btw.

In case anyone cares.

cgf


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