[Issue 2837] New: OPTLINK and LARGEADDRESSAWARE

d-bugmail at puremagic.com d-bugmail at puremagic.com
Wed Apr 15 10:39:28 PDT 2009


http://d.puremagic.com/issues/show_bug.cgi?id=2837

           Summary: OPTLINK and LARGEADDRESSAWARE
           Product: D
           Version: unspecified
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Optlink
        AssignedTo: bugzilla at digitalmars.com
        ReportedBy: bugzilla at digitalmars.com


Vladimir Panteleev writes:

It seems that OPTLINK doesn't support the IMAGE_FILE_LARGE_ADDRESS_AWARE flag
(enabled with /LARGEADDRESSAWARE when using Microsoft Link), even though the D
runtime seems to support it.

Consider this simple program:

-----------------------------
import std.stdio;

void main()
{
    ubyte[][4096] a; // GC anchor
    for (int i=0;;i++)
    {
        writefln(i);
        a[i].length = 1024*1024;
    }
}
-----------------------------

This program crashes when it tries to allocate the 1618th megabyte, even though
my PC has 6 GB of RAM and the 32-bit address space allows for much more.

I've patched the executable and enabled the IMAGE_FILE_LARGE_ADDRESS_AWARE
flag. This flag is 0x0020 in the "Characteristics" field in the
IMAGE_FILE_HEADER structure. In OPTLINK-generated executables, one can enable
this flag manually by changing byte 0x76 from 0x8E to 0xAE in the executable
file.

The result - the program can now allocate 3319 megabytes on my machine, thus
practically doubling its address space.
(Why is it still not anywhere near the theoretical limit?)

I've patched my copy of the linker until the official linker is updated. If
anyone wants to use more than 2 (or 1.6?) GB in their DMD/Windows programs,
change the byte at 0x3CF0D in link.exe from 0x8F to 0xAF.


-- 



More information about the Digitalmars-d-bugs mailing list