This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: data and bss tests in dll_list::alloc
- From: VÃclav Zeman <vhaisman at gmail dot com>
- To: cygwin-developers at cygwin dot com
- Date: Wed, 8 Feb 2012 16:31:57 +0100
- Subject: Re: data and bss tests in dll_list::alloc
- References: <20120208145419.GM25129@calimero.vinschen.de>
On 8 February 2012 15:54, Corinna Vinschen wrote:
> Hi,
>
>
> I just fixed a typo in the fabort calls in dll_list::alloc. ÂBut in fact
> I'm wondering if we really need the extensive data_start/data_end/
> bss_start/bss_end tests. ÂThe reason is simple. ÂAll DLL segments are
> always loaded into adjacent addresses, always in the order given by
> the DLL segement information.
>
> Therefore, a single address comparison is sufficient to recognize a
> situation in which a child DLL is not loaded to the same address as
> in the parent.
>
> And given that, we don't even have to compare data and bss addresses
> at all. ÂThe HINSTANCE is the address of the module. ÂJust compare it
> to the stored d->handle and if they are not identical, we're done,
> right?
>
> Or am I missing something?
I think that this article about Windows 2000 loader supports that:
<http://msdn.microsoft.com/en-gb/magazine/cc301727.aspx>
> "Now that LdrpMapDll has the section handle, it can actually load the DLL into the process's address. The DLL is brought in as a memory-mapped file through the services of NtMapViewOfSection."
My understanding is that the DLL sections are mapped in in the order
they are stored in PE executable headers, each adjacent to the
previous one.
--
VZ