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] |
On Wed, Feb 08, 2012 at 04:41:52PM +0100, Corinna Vinschen wrote: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.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?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |