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 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


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