In a typical Linux system, the addresses 0-3fff.ffff (3 gigs) are available for the user program space.
Exectuable binary files include header information that indicates a load address. Libraries, because they are position-independent, don't need a load address, but contain a 0 in this field.
Our proposed design has normal executables loading like this:
Start Len Usage
0 4k zero page
0000.1000 32M not used
0200.0000 960M app code/data space
after the app is the small malloc space
(sys_brk)
4000.0000 1G mmap space
includes library load space (code & data)
& large malloc space
8000.0000 1G stack space, working down from bfff.ffe0
The kernel has a preferred location for mmap data objects, at 0x4000.0000. Since the libraries are loaded by mmap, they end up here.
The library that we are using for malloc handles small mallocs by calling sys_brk(), which extends the data area after the app, at 0x0200.0000+sizeof(app). Large mallocs are realized by creating a mmap, so these end up in the pool at 0x4000.0000.
As the mmap pool grows upward, the stack grows downward. Between them, they share 2G bytes.
There is a separate case. The shared library design usually has the app loading first, then the loader notices that it need support, and loads the dyn-loader library (ld.so.1 or ld-linux.so.1) at 0x4000.0000. Other libraries are loaded after ld.so.1.
There is a diagnostic case where the app is invoked by
ld.so.1 foo_app foo_arg ....
In this case, the ld.so.1 is loaded as an app. Since it is a library, it tries to load a 0. In ArmLinux, this is forbidden, so the kernel pushes it up to 0x1000. Once ld.so.1 loads, it reads it argv[1] and loads the foo_app at its preferred location (0x0200.0000). Other libraries are loaded up at the mmap area. So, in this case, the user memory map appears as:
Start Len Usage
0 4k zero page
0000.1000 32M ld.so.1
after it the small malloc space (sys_brk)
0200.0000 960M app code/data space
4000.0000 1G mmap space
includes library load space (code & data)
& large malloc space
8000.0000 1G stack space, working down from bfff.ffe0
Notice that the small malloc space is much smaller in this case, but this is supposed to be for load-testing and diagnostics, so it's not too bad.