Re: [PATCH] rebase: fix 32-bit rollover

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Feb 11 12:24, Yaakov (Cygwin/X) wrote:
> On 2014-02-11 04:22, Corinna Vinschen wrote:
> >On Feb 10 15:07, Yaakov (Cygwin/X) wrote:
> >>When running rebase on multiple DLLs for x86, downwards rollover is
> >>now going back to the top of the 64-bit address space, which isn't
> >>right for x86 images.  This patch should restore the previous
> >>behaviour of rolling over (under?) to the top of the 32-bit space
> >>instead.  I didn't attempt to deal with upwards rollover due to the
> >>following comment.
> >
> >Thanks for catching.  We should not rollover indiscriminately into the
> >upper two gigs either, though.  It won't work for real 32 bit systems,
> >only for WOW64 systems.
> >
> >But given that rebase is running on a specific machine, we could take
> >the WOW64-iness into account.
> >
> >Also, rebase should not start at the upper bound, because it will
> >collide with PEB, TEB and shared-user-data anyway, see the output of
> >/proc/$PID/maps.
> >
> >AFAICS, we should start at either 0xfffe0000 (WOW64) or 0x7f60000
> >(real 32 bit).
> >
> >Does that make sense?
> 
> I think so, but in parse_args it allows for -b to be anywhere in the
> 4GB space for ix86.  Should that not be allowed if not on WoW64
> either?

I don't really worry if the user sets the value explicitely, but if
you have fun to change that, I guess it won't hurt.

> Also, on ix86 systems, should /3GB configurations (bcdedit /set
> IncreaseUserVa in newer versions of Windows) be taken into account,
> and how?

In theory the GlobalMemoryStatusEx functions should do it.  Check the
ullTotalVirtual member of the returned MEMORYSTATUSEX struct.

Alternatively check the TEB address of the main thread as returned by
NtCurrentTeb().  The TEB is always in the upper 1 Megs of the available
virtual address space.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpED4GK0PD0H.pgp
Description: PGP signature