Message-ID: <4B673D5F.4050104@gmail.com>
Date: Mon, 01 Feb 2010 20:45:19 +0000
From: Andrew <andrewwest@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8pre) Gecko/20100131 Shredder/3.0.2pre
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: dlclose not calling destructors of static variables.
References: <4B61732F.4030804@gmail.com>  <4B62DDE6.5070106@gmail.com>  <4B62F118.8010305@gmail.com>  <20100129184514.GA9550@ednor.casa.cgf.cx>  <4B66BF2F.4060802@gmail.com>  <20100201162603.GB25374@ednor.casa.cgf.cx>  <4B6710CE.40300@gmail.com>  <20100201174611.GA26080@ednor.casa.cgf.cx> <20100201175123.GB26080@ednor.casa.cgf.cx> <4B672B74.4090808@gmail.com>
In-Reply-To: <4B672B74.4090808@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On 01/02/10 19:28, Dave Korn wrote:
> On 01/02/2010 17:51, Christopher Faylor wrote:
>    
>> On Mon, Feb 01, 2010 at 12:46:11PM -0500, Christopher Faylor wrote:
>>      
>    
>>>> Cribbing from the gdb source code, it looks like they use BaseAddrees +
>>>> 0x1000 for the start point and then call GetModuleInformation to workout
>>>> the size of the module.
>>>>          
>>> Yeah, duh.  "they" == "me".  I should have checked gdb for this since I've
>>> already done this research once before.
>>>
>>> If you do find that this works, then I think this may fall into the
>>> realm of a non-trivial patch so it may be best to just tell me what
>>> you've found rather than provide a patch - unless you want to go through
>>> the approval process with Red Hat.
>>>
>>> Or, you can just wait for me to adapt what's in gdb to cygwin.  I can do
>>> tonight when I get back to a windows system.
>>>        
>> Btw, it isn't entirely clear that GetModuleInformation will work with
>> older versions of Windows NT so this may not be a complete solution.  We
>> do use GetModuleInformation in Cygwin but it is not in anything as
>> crucial as this.
>>      
>    Can't we use the info in the dll struct?  It has pointers to the data and
> bss section, we could take the max out of them and the data in the M_B_I
> struct.  (Tell you what, I'll try it.)
>
>    

That would be the ideal solution.

I'm not looking to submit a patch to fix this, I'll leave that up to the 
professionals
who have a better idea about the whole picture. It's just I've hit a 
brick wall with
my code with this bug so I'm looking for some work arounds for myself.

I'm going to poke around the "remove_dll_atexit" function again tomorrow.
gdb used bfd_* functions from binutils so that's out for me, 
VirtualQuery seems
wrong for purpose and GetModuleInformation keeps giving me a invalid 
handle error.
Iterating over the dll list and using the per_module information seems 
like my best bet,
and hopefully should be quite simple I think.

Andy.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple