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


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