[PATCH] Add an additional relocation attempt pass to load_after_fork()
Christopher Faylor
cgf-use-the-mailinglist-please@cygwin.com
Tue Apr 5 16:22:00 GMT 2011
On Tue, Apr 05, 2011 at 05:03:43PM +0100, Jon TURNEY wrote:
>On 04/04/2011 15:39, Christopher Faylor wrote:
>> On Mon, Apr 04, 2011 at 01:42:54PM +0100, Jon TURNEY wrote:
>>> Attached is an updated version of the patch which fixes the warning identified
>>> by Yaakov.
>>>
>>> I've also attached a slightly cleaned up version of the additional fork
>>> debugging output patch I was using.
>>
>>>
>>> 2011-03-12 Jon TURNEY <jon.turney@dronecode.org.uk>
>>>
>>> * dll_init.cc (reserve_at, release_at): New functions.
>>> (load_after_fork): Make a 3rd pass at trying to load the DLL in
>>> the right place.
>>
>> Rather than add a new pass could we just add rename/enhance "reserve_upto" so
>> that it both reserves the block of memory up to the dll's preferred load address
>> and the block of memory erroneously occupied by the dll? Or is the extra step
>> important?
>
>I don't know if the 2nd and 3rd passes can be combined.
>
>From observation, the behaviour of LoadLibraryEx() seems to be to load the DLL
>at it's base address if it can, otherwise the lowest available address. If
>that's accurate then there doesn't seem to be any harm in combining them
>(as pass 3 will always succeed in successfully remapping the DLL if pass 2
>would have), but that's based on my limited observations on a single Windows
>version.
>
>I guess I'm just being conservative to avoid the possibility of a regression
>if there are circumstances I don't know about where pass 2 would succeed but
>pass 3 would fail.
I'm trying to imagine a scenario where it would screw up to just do the
reserve_upto + "reserve the low block" and I can't think of one. It's
potentially a little more work, of course, but I think it may catch the
more common failing conditions so it shouldn't be too noticeable.
>> If so, it seems like we're allocating and freeing the space up to the DLL more
>> than once. I think we could avoid doing that.
>
>For performance reasons, I think you are right. Or do you mean there is a
>correctness issue with that?
>
>If you indicate your preferences I'll respin the patch.
>
>1) Combine passes 2 and 3
I'd prefer this. If we can get people test the snapshot maybe we an
figure out if a separate loop is useful.
cgf
More information about the Cygwin-patches
mailing list