Bug 204536 - want more contiguous user space for 32-bit process on 64-bit hardware
Summary: want more contiguous user space for 32-bit process on 64-bit hardware
Status: REPORTED
Alias: None
Product: valgrind
Classification: Unclassified
Component: memcheck (show other bugs)
Version: 3.5.0
Platform: Compiled Sources Linux
: NOR wishlist (vote)
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-20 16:32 UTC by John Reiser
Modified: 2014-05-22 05:50 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
patch to use 0xEC000000 for 32-bit tool on 64-bit hardware (3.14 KB, patch)
2009-08-20 16:34 UTC, John Reiser
Details

Note You need to log in before you can comment on or make changes to this bug.
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 :)