[patch/rebase]: Makefile support for cross-builds and static linking with gcc-4

Charles Wilson cygwin@cwilson.fastmail.fm
Tue Jun 21 14:27:00 GMT 2011

On 6/21/2011 4:06 AM, Corinna Vinschen wrote:
> Btw., did anybody experiment with setting the ASLR flag for DLLs?
> Chuck's description sounds as if this really might help to reduce
> collision problems at fork time.  If so, the ASLR flag should 
> become default for DLLs.

(1) I thought the end result of those experiments was that it really
didn't help, and sometimes hurt...especially as Reini wrote last december:

>> I'm trying now to turn off ASLR: peflags -d0 for all perl dll's.
> Yes. Adding a -d0 solved so far the problems on Win7 for me.

More recently on the mingw list:
>> I thought we (on cygwin) had pretty much come to the conclusion that
>> chasing after ASLR and peflags -d0
[ed: that is, turning ASLR *off*]
>> was a red herring?  Well, I guess
>> it's not too hard to patch the Makefile to run peflags on miniperl...
> Not really. I tested recently perls on Windows 7 with peflags -d1
[ed: that is, with ASLR turned on]
> and
> came to the conclusion that in perl forking a perl which load dll's
> (XS) we get random problems.

(2) Most of the problems lately seem to occur with 64bit OS's. I think
your idea of rebasing into high memory on those systems is something
good to try -- but in that case, ASLR will not apply anyway:

    a global bitmap called _MiImageBitMap is used to represent
    the address space from 0x50000000 to 0x78000000. The bitmap
    is 0x2800 bits in length with each bit representing 64KB
    of memory.

With regards to #1, we had a long thread a few years ago, where we
investigated an issue where DLLs would allocate memory 'right next to'
their own .text segment -- but this extra memory doesn't show up in the
"next_dll_image_base = my_dll_image_base + my_dll_image_size"
calculation.  Hence, boom.  We "solved" the problem by explicitly
increasing the rebaseall offset to 0x20000, and fixing one other issue
related to allocating a large buffer for a filename in the PEB or something:
http://cygwin.com/ml/cygwin/2009-06/msg00266.html (*)

One statement in that thread:
> In that sense, ASLR would be a disimprovement over what we can do with
> rebase, because we can apply a larger quantization (e.g.
> DefaultOffset=0x20000).
referred the fact that ASLR will *always* compute the next image base
based on a 64k quantization size, and can't be 'tweaked' to make room
for allocations in the first dll, that happen after the "next" dll is
loaded and ASLRed.

so, the upshot is, I'm not sure if ASLR really is a silver bullet, since
Reini's experiments in late 2010 are certainly after the buffer-size
changes from June 2009.

I'd love to be wrong...


(*) This series of patches, I believe
2009-06-06  Corinna Vinschen  <>

  * dll_init.cc (dll_list::alloc): Allocate memory using a section
  object.  Explain why.  Drop call to GetSystemInfo, rather call
  getpagesize to get allocation granularity.  Only align to allocation
  granularity under WOW64.  Use roundup2 to align.
  (dll_list::detach): Call NtUnmapViewOfSection instead of VirtualFree.

2009-06-06  Corinna Vinschen  <>

  * mmap.cc: Use NtUnmapViewOfSection instead of UnmapViewOfFile
  throughout for symmetry.
  (fhandler_dev_mem::munmap): Use correct process handle in call to

2009-06-06  Corinna Vinschen  <>

  * dll_init.h (struct dll): Set size of name element to ANYSIZE_ARRAY.
  * dll_init.cc: Fix formatting.
  (dll_list::alloc): Only allocate as much memory for struct dll as
  necessary for given DLL name.
  (dll_list::load_after_fork): Only read a single page of parent memory.
  Only read more if namelen indicates that it's necessary.

More information about the Cygwin-apps mailing list