This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
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