Printable View
I'm debugging a program that I wrote and I notice several things:
variables and pointers within a current function are stored on stack frames located at: 0xbf******
malloc() allocates my pointers to: 0x80******
Does it always always use bf and 80? What do we call 0x80 (I know we call 0xbf the stack)
That's just how your particular implementation works.
Malloc memory comes from the heap.
Those addresses would probably be different if you ran the program on a different computer, or ran a few other programs and then ran yours. (To take up more memory.)
It looks to me like the high numbers are in the stack and the low ones on the heap. What do CPU register addresses look like and will I ever see them?
Registers are not mapped to memory addresses. They are identified in a different way.Quote:
Originally Posted by MK27
If thats the case, then are constants (#DEFINE) stored on the stack or heap?
#define's are replaced in the source code before compiling.
Well actually they are stored in .bss when compiled and linked. What part of the memory segment are they located at when the program is executed? Stack or heap?Quote:
Originally Posted by anon
Program data.Quote:
Originally Posted by someprogr
#defines disappear before the proper compiler sees the code - this is the job of the C preprocessor .Quote:
Originally Posted by someprogr
.bss is part of data in most systems, but sometimes it is considered it's own section (but in most parts equivalent to .data).
Based on the numbers you quote for the stack addresses and heap addresses, I guess that you are using Linux on x86 with a 32-bit build of Linux (and the OS is set up for 1GB of Kernel space, rather than the settings used in Linux kernels in ancient times, wher the user-space was 1GB and kernel space had 3GB to play with). In this setup, the stack is located at the highest address that is available to the user-mode code, 0xC0000000, and the stack grows towards zero.
The heap, as it happens, starts at a low address, and grows towards the stack. This is a fairly common scenario, but it by no means HAS to be this way. The OS and software that loads/builds applications can do these things just about any way they like. There are restrictions with regards to the processor architectue (e.g. in x86, it would be nigh on impossible to create a system where the stack grows towards higher addresses - because you would have to replace all CALL and RET instructins with a "store the address we want to return to on the reverse-growing stack" and use a "restore from stack then jump" - it could be done, but it's hard work [and you almost certainly couldn't do that for the OS kernel].
Note that stack, heap, data, bss and code are all the same type of memory chips. Code is slightly different in the sense that the memory is tagged in the MMU [1] as executable and read-only, whilst data is not executable [2]. Other than that, it's just a suitable way of collecting parts of application that is similar together in one lump, rather than having a bit of code, a bit of data, a bit of this, and bit of that all over the place in some "as needed" arrangment.
[1] MMU is what translates your applications virtual address into a physical location in memory. As you may have seen, all applications appear to use the same address in memory, even if they are executing at the same time. That obviously wouldn't work [unless we shuffle A LOT of code and data around on each task-switch, that is], so the CPU itself has a MMU (Memory Management Unit) that "maps" the addresses that the application sees onto the physical addres of the memory.
[2] Some older processors may not be able to distinguish between executable and non-executable memory - but those that do, will mark Code as executable.
--
Mats