Hi,
Does any one know what tool to use to visualize how is memory layed out for C on linux systems. I mean how much stack portion is used in functional call.
Where exactly does the argument to function sit in memory ?
I have written small program pasted below. But I am not able to infer anything with the output I am getting.
(attached is the c code)
Global variable 'add' is used to locate the stack's base.
I don't know if this technique works ? waiting for your views
Regards,
Kiran
Suggestion -
try compile gcc -S myfile.c
This produces an assembler source file.
Or try
cat /proc/<c process pid>/maps
I'm assuming you mean linux for 32-bit x86. PPC, for example, would be very different.
It depends. I've seen gcc do a lot of 'cheating' to avoid writing to the stack, like passing floating point arguments in SSE registers. Compiling with -O0 ought to avoid stuff like that.
I figured it out by brute force, reading upwards in memory until my program segfaulted. On 32-bit x86 linux, the base of the stack is at 0xffff000, which is exactly 4096 bytes less than the highest possible address(0xffffffff). This is probably not a coincidence, since 4096 bytes is is the page size on my system(yours might be 8192); this means it's precisely one memory page away from the bottom of memory.
If you mean base as in where the stack pointer is right at that moment, taking the address of a local variable would be pretty close.
Well, what is in memory is just as important as where it's in memory. I don't think you'll be able to see the big picture without printing out whole parts of it and seeing what changes when you do what. Pick numbers you can easily recognize and you'll find them. This may be the world's only practical application of leet -- 0xACC01ADE, 0xB01DFACE, 0x1ABE11ED, 0xC0A1FACE, etc. are fairly easy to notice. Here's the first couple lines of output from my program:
# ./a.out
Address of main() is 0x8048544
Address of test_stack() is 0x8048518
System page size is 4096 bytes
0xffffce80-0xffffce8f: 98ceffffbebafecab8ceffffb8850408 ................
0xffffce90-0xffffce9f: de1ac0ac1e0db0cab8ceffff68816a55 ..... ......h.jU
0xffffcea0-0xffffceaf: d3f05b55f46f6a5534970408f46f6a55 ..[U.ojU4....ojU
0xffffceb0-0xffffcebf: 00000000efbeadde18cfffff11905a55 ..............ZU
0xffffcec0-0xffffcecf: 0100000044cfffff4ccfffff9a055655 ....D...L.....VU
0xffffced0-0xffffcedf: f46f6a550000000080ac565518cfffff .ojU......VU....
0xffffcee0-0xffffceef: c0ceffffd68f5a550000000000000000 ......ZU........
0xffffcef0-0xffffceff: 00000000b4af56550100000050830408 ......VU....P...
0xffffcf00-0xffffcf0f: 00000000d00456552b8f5a55b4af5655 ......VU+.ZU..VU
0xffffcf10-0xffffcf1f: 01000000508304080000000071830408 ....P.......q...
0xffffcf20-0xffffcf2f: 448504080100000044cfffffc0850408 D.......D.......
0xffffcf30-0xffffcf3f: 10860408d00d56553ccfffffd0b45655 ..... VU<.....VU
0xffffcf40-0xffffcf4f: 01000000f4d0ffff00000000fcd0ffff ................
...
Sure enough, see that "bebafeca" somewhere between 0xffffce80 and 0xffffce8f? That's 0xCAFEBABE with the bytes backwards. Also see that "44850408" starting at 0xffffcf20? That's part of main()'s address. The whole thing won't be the same since it's returning to somewhere in the middle of main instead of right at the beginning, but it's close.
There's a lot more than function calls on the stack, by the way. Suppose it's run like:
# ./a.out HERE ARE THE COMMAND LINE PARAMETERS
...
0xffffd0c0-0xffffd0cf: 0000000000000000000069363836002e ..........i686..
0xffffd0d0-0xffffd0df: 2f612e6f757400484552450041524500 /a.out.HERE.ARE.
0xffffd0e0-0xffffd0ef: 54484500434f4d4d414e44004c494e45 THE.COMMAND.LINE
0xffffd0f0-0xffffd0ff: 00504152414d4554455253004d414e50 .PARAMETERS.MANP
0xffffd100-0xffffd10f: 4154483d2f7573722f6c6f63616c2f73 ATH=/usr/local/s
0xffffd110-0xffffd11f: 686172652f6d616e3a2f7573722f7368 hare/man:/usr/sh
0xffffd120-0xffffd12f: 6172652f6d616e3a2f7573722f736861 are/man:/usr/sha
0xffffd130-0xffffd13f: 72652f62696e7574696c732d64617461 re/binutils-data
0xffffd140-0xffffd14f: 2f7838365f36342d70632d6c696e7578 /x86_64-pc-linux
0xffffd150-0xffffd15f: 2d676e752f322e31362e312f6d616e3a -gnu/2.16.1/man:
...
Sure enough, there they are, and after that, environment variables.
So, I can't give you a precise definition for your system, but you can piece some things together with eyesight.
thanks for that ..
What I was thinking was how well can a programmer organize himself for making optimal use of stack and memory.
For example declaring unused variables, passing huge arguments to the function and repeated malloc ( where a static variable can be used ) are not recommonded.
Similar to this, do we have some set of issues related with memory management that a programmer tend to overlook.
What I have observered is that people ( including me) have superficial idea about the memory layout and make a simple task on user side, very difficult on system side and do not realize the impact.
Regards,
Parasa Kiran