UNIX for Advanced & Expert Users

All of my machines (various open source derivatives on x86 and amd64) store argv above the stack (at a higher memory address). I am curious to learn if any systems store argv below the stack (at a lower memory address).

I am particularly interested in proprietary Unices, such as Solaris, HP-UX, AIX, etc, although any reports are welcome. Please don't neglect to mention your operating system and cpu architecture in your post.

If you are inclined to help, please compile and execute the following small program:

Code:

#include <stdio.h>
#include <unistd.h>

int
main(int argc, char **argv)
{
    int x;

    printf("heap: %p\n", sbrk(0));
    printf("stack: %p\n", (void *) &x);
    printf("argv: %p\n", (void *) &argv);
    return 0;
}

The "stack: " line is just an approximation to the top of the stack, but it's good enough for my purposes.

A typical result from a 32-bit x86 Linux system:

Code:

heap: 0x804a000
stack: 0xbf9023ac
argv: 0xbf9023d4

Thank you in advance,
Alister

Hi Alister, here are some results, all 64-bit systems:

Code:

OSX 10.8 (INTEL)
--------------------
heap: 0x105a19000
stack: 0x7fff5a21ab84
argv: 0x7fff5a21ab90

Code:

Solaris 10 (SPARC)
--------------------
heap: 20e30
stack: ffbffc28
argv: ffbffc78

Code:

HPUX11v1 (PA-RISC)
--------------------
heap: 400010ec
stack: 7f7f0668
argv: 7f7f0638

Code:

AIX 7 (Power4)
-------------
heap: 200006ec
stack: 2ff22bf8
argv: 2ff22c3c

Code:

Irix 6.5 (MIPS)
--------------------
heap: 10014000
stack: 7fff2f28
argv: 7fff2f24

Code:

Tru64 5.1 (Alpha)
--------------------
heap: 14000e180
stack: 11fffbfe0
argv: 11fffbff8

Wow. Thank you very much for that post, Scrutinizer. I appreciate it.

It seems that HPUX and IRIX are the odd ones out (stack grows to higher memory addresses).

If it were not vulgar, I would express my multi-UNIX access envy, but I always try to keep my posts chaste.

Regards,
Alister

Solaris 10 SPARC, 32bit:
heap: 20de0
stack: ffbfe930
argv: ffbfe980

Solaris 10 SPARC, 64bit:
heap: 100100d10
stack: ffffffff7fffe6d8
argv: ffffffff7fffe6e0

Solaris 10 x68, 32bit:
heap: 8060890
stack: 8047de4
argv: 8047df4

HP-UX 11 PA-RISC2.0, 32bit:
heap: 400010e4
stack: 7a000f98
argv: 7a000f68

HP-UX 11 Itanium, 32bit:
heap: 40010048
stack: 7ffff3c0
argv: 7ffff3dc

I guess that PA-RISC is the exotic hardware. And MIPS.

Thank you, MadeInGermany, for illuminating the distinction between HP-UX PA-RISC and Itanium. Much appreciated.

Regards,
Alister

Output:
heap: 20dd8
stack: ffbffc84
argv: ffbffcd0

System Configuration: Oracle Corporation sun4v SPARC T4-2

Hope that helps.
Regards
Peasant.

I have a vague recollection of the address space layout shifting a few times with changes in CPU architectures. First there was the IBM 360 architecture, then the 16-bit address space PDP-11, then the 17-bit address space PDP-11, then the VAX, then the 3B20, 3B2, 3B5, M68K, SPARC, PA RISC, etc., and the segmented address space of the various x86 and similar processors. The people that did the ports to each new architecture decided at that time where code, text, heap, and stack would be placed for that architecture. For various reasons, they were not all in the same order. But, once an order was chosen for a particular processor type, ABI considerations tended to use the same layout for all systems based on that architecture. (Some companies (e.g., Intel) caused some unnecessary incompatibilities by not letting various contractors working on different OSes for the same architecture talk to each other and giving different answers to trivial questions like whether some numbers were presented in decimal or octal in tables that Intel created and then shared with the contractors.)