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: data and bss tests in dll_list::alloc


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


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