data and bss tests in dll_list::alloc

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Wed Feb 8 16:40:00 GMT 2012


On Wed, Feb 08, 2012 at 05:33:16PM +0100, Corinna Vinschen wrote:
>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.

I know it's a valid DLL but I'm wondering if it ever shows up in the wild.

But, nevermind, it's easy enough to detect in the code so it's a moot
point.

cgf



More information about the Cygwin-developers mailing list