Re: data and bss tests in dll_list::alloc

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Feb  8 11:26, Christopher Faylor wrote:
> On Wed, Feb 08, 2012 at 04:41:52PM +0100, Corinna Vinschen wrote:
> >On Feb  8 10:21, Christopher Faylor wrote:
> >> On Wed, Feb 08, 2012 at 03:54:19PM +0100, Corinna Vinschen wrote:
> >> >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.
> >> 
> >> If that is the case can we simplify the child_copy operation?  That
> >> would speed up fork slightly.
> >
> >I'm not sure, but if you're asking if we can only give a single address
> >to child_copy, then the answer is probably no.  You can't rely on the
> >fact that data and bss segments are adjacent segments in the DLL, just
> >that adjacent segments in the DLL will be loaded into adjacent addresses
> >in the processes VM.
> 
> I thought you were implying that data/bss load order was always the same.
> It is isn't it?

No, it's not.  If you have a DLL with four segments:

 .text
 .data
 .bss
 .rdata

Then these segments are always loaded in the given order in adjacent
memory locations.  But this:

 .text
 .data
 .rdata
 .bss

is a valid DLL, too.  The segments will be loaded in the given order in
adjacent memory locations as well, but the .rdata segment might be read
only, for instance.  If you try to copy it in copy_child it will fail.


Corinna

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