data and bss tests in dll_list::alloc

[Ryan Johnson]

On 08/02/2012 11:26 AM, 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?
My understanding is that the bss and data segments usually don't occupy 
the same positions in the dll-as-file that they do in the 
dll-as-mmaped-entity (what Corinna said), but that any two mapped 
instances of a dll would put data/bss in consistent positions relative 
to the dll's base (what CGF wonders). However, we'd want to confirm that 
data/bss were actually adjacent before firing off a single memcpy.

Does that make sense or am I misunderstanding the issue?

Ryan