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: Large-Address awareness on 64 bit systems


On Jun 19 02:24, Yaakov (Cygwin/X) wrote:
> On Sat, 2011-06-18 at 22:17 +0200, Corinna Vinschen wrote:
> > That means, if we make all Cygwin binaries large address aware, somebody
> > using a 64 bit system could rebase all Cygwin DLLs, except for the
> > Cygwin DLL itself into the virtual memory area beyond 0x80000000.  Given
> > that this memory area is not at all used by Windows itself, it's free
> > for usage by Cygwin alone.  This would affect the memory allocation not
> > only for Cygwin DLLs, but also for mmaps and for thread stacks, which
> > both use the MEM_TOP_DOWN flag.
> > 
> > If I get this right, this should ease the fork pain due to memory collisions
> > on 64 bit systems quite a lot.
> 
> Sounds great.
> 
> > This obviously also affects all non-distro executables, such as self-
> > compiled stuff.  All of them need the --bigaddr flag set, too.
> 
> It would be helpful if there were a short option for --bigaddr.
> 
> > Therefore it might be quite tricky to maintain a sane system, given that
> > gcc creates executables with the large address awareness flag switched
> > off, and given the fact that the flag is reset for a distro executable
> > every time it gets updated via setup.
> 
> Are there any downsides to large address awareness, particularly for
> 32bit systems or those with less than 4GB?  IOW is there any reason not
> to switch this on by default in gcc/ld?

I don't see any problem.  Cygwin does not use the high bit of a pointer
as a flag for something and hopefully no other DLL or applications does
that.

> > However, if anybody feels confident to test this on the own machine,
> > I'd be curious if that has the desired effect of letting fork work
> > more reliable.  I'm not sure I have the required use cases to test
> > this sufficiently.
> 
> But I think I do. :-)  I have rebased and reflagged my system
> accordingly, and so far (running GNOME 3 desktop) so good.  I'll keep
> you posted.

Great, thanks!  As I just wrote in my reply to Ryan, I even rebased the
Cygwin DLL(*) and it runs fine for me.


Corinna

(*) First I called rebaseall -b 0xe0000000(**), then I copied over the
    Cygwin DLL to cygwin1.X.dll, rebased it to 0xe1000000, exited
    Cygwin and moved cygwin1.X.dll over to cygwin1.dll.

(**) Btw., to avoid collisions in apps using mmap a lot, it might be
     better to rebase to a lower address.  One has to keep in mind how
     big the large address area is, it's the same size *again* a process
     has on a default installation.  Therefore something like rebaseall
     -b 0xa0000000 might be more helpful.

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


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