data and bss tests in dll_list::alloc

Corinna Vinschen corinna-cygwin@cygwin.com
Wed Feb 8 15:44:00 GMT 2012


On Feb  8 16:31, Václav Zeman wrote:
> 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.

Yep, that;'s what I meant.  I never saw a case where DLL segments were
loaded into arbitrary addresses spreaded over the processes VM.  Having
a single load address in the PE/COFF header doesn't make much sense
then, and it's much more work for the loader as well.


Corinna

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



More information about the Cygwin-developers mailing list