Bug 204536

Summary: want more contiguous user space for 32-bit process on 64-bit hardware
Product: [Developer tools] valgrind Reporter: John Reiser <jreiser>
Component: memcheckAssignee: Julian Seward <jseward>
Status: REPORTED ---    
Severity: wishlist CC: austinenglish
Priority: NOR    
Version First Reported In: 3.5.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: patch to use 0xEC000000 for 32-bit tool on 64-bit hardware

Description John Reiser 2009-08-20 16:32:38 UTC 
Version:           3.5.0 (using Devel)
Compiler:          gcc (GCC) 4.4.0 20090506 (Red Hat 4.4.0-4) 
OS:                Linux
Installed from:    Compiled sources

When a 32-bit executable program is run on a 64-bit Linux, then the process gets a larger 32-bit address space because the operating system kernel no longer occupies virtual address space in the low 4GB.  The user space allowed by the kernel typically grows from the interval [0, 3GB) to the interval [0, (4GB - 64KB)).  Instead of fragmenting that interval by residing at 0x38000000, valgrind tools ought to allow as much contiguous user space as possible.  I suggest using 0xEC000000 instead of 0x38000000.  (The kernel puts the use stack near the high end, so fixed addresses >= 0xF0000000 can cause trouble.)  This would allow user processes with very large .bss or .data.  It would also get memcheck out of the way of Wine, which wants to reserve [0, 0x60000000) and [0x7f000000, 0x81000000) for Win32 uses.  As soon as the KDE Bug Wizard lets me, I'll attach a patch.
Comment 1 John Reiser 2009-08-20 16:34:15 UTC 
Created attachment 36302 [details]
patch to use 0xEC000000 for 32-bit tool on 64-bit hardware
Comment 2 Austin English 2014-05-22 05:40:38 UTC 
Looking at the source, 0x38000000 is still the default (pre 3.6.0).
Comment 3 Austin English 2014-05-22 05:50:56 UTC 
(In reply to comment #2)
> Looking at the source, 0x38000000 is still the default (pre 3.6.0).

Just realized that the mirror I used it obviously out of date, sorry about that. Still present in pre 3.10.0 :)