Which way does the stack go?

Aside from your empirical evidence, I can confirm that the stack (in x86) grows from a (seen as an unsigned value) high numerical value towards zero. There is no (reasonably sane) way you can make an x86 processor do the other way around. Other processors are generally the same, but there's nothing saying the stack could not start at a numerically low address and grow towards a higher address.

Note also that the heap is not at all guranteed to be anywhere in particular in relation to the stack - the stack can be placed before, after or in the middle of the heap-space.

--
Mats

Quote:

---

Originally Posted by matsp

Aside from your empirical evidence, I can confirm that the stack (in x86) grows from a (seen as an unsigned value) high numerical value towards zero. There is no (reasonably sane) way you can make an x86 processor do the other way around.

---

All you have to do is set the Direction/Conform bit in the stack segment descriptor. All stack-related instructions will then operate in a "grow upward" mode when accessing that segment.

Quote:

---

Originally Posted by brewbuck

All you have to do is set the Direction/Conform bit in the stack segment descriptor. All stack-related instructions will then operate in a "grow upward" mode when accessing that segment.

---

No, that only determines how the limit is used against the base-value. If you set it one way (zero, I think), it has a base .. base + limit range, in the other way, the range is base - limit .. base. This allows for growing the stack by simply changing the limit, rather than modifying both limit and base. [And no, I didn't even take the book out to validate that]

It does not change which way the push or pop instructions work, or call/return, interrupts/iret store/restore data to/from the stack. A push, call and interrupt will decrement the stack-pointer, and the pop, ret, iret instructions will increment the stack. No choices there. You could of course do your own stack-manipulation with mov and add/sub [but it will not be atomic in any way shape or form, unless you wrap every "push"/"pop" operation in a lock/cli type operation].

--
Mats

Quote:

---

Originally Posted by matsp

No, that only determines how the limit is used against the base-value. If you set it one way (zero, I think), it has a base .. base + limit range, in the other way, the range is base - limit .. base. This allows for growing the stack by simply changing the limit, rather than modifying both limit and base. [And no, I didn't even take the book out to validate that]

---

Yeah -- seems Intel's docs agree with you. I based my statement off information from a non-Intel-endorsed protected-mode architecture book from the mid-90's. It seems the book was wrong, or at least extremely misleading. Good to know.

Also reviewing your memory mappings of the PID of the running process in question in the /proc/[PID]/maps directory will shed some good clues toward further investigation of memory allocations.