I vaguely remember a similar thread was posted many months back, but I couldnt trace it.
I wish to know the actual events that occur when a program is being executed. Like how the space is allocated when a call to "malloc" is made and such other inticate detials. Can someone guide me to some online resource where I can find such issues?
In the middle of difficulty, lies opportunity
Do you have a specific platform in mind?
The general answer is pretty vague
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
yeah.. linux Ofcourse
In the middle of difficulty, lies opportunity
Are you talking about the stack view and memory addressing?
Do you understand Assembly language?
Hello. I wondered the same thing when I first started programming. How does
malloc() do what it does? How does prinf() put stuff on the screen, etc. Learn binary and
assembly language. On Linux, compile your program with gcc -g program.c -o program.
After compiling your program with the -g option
type --> gdb program
Once in gdb (all done on command prompt)
type --> b main or break main and press <ENTER>
then type --> display /i $pc and press <ENTER> (This will show the assembly intructions
that are being executed as you step through your program).
then type --> r or run then type either si (single step) or n to step machine instruction
by machine instruction through your code.
In short, using gdb will allow you to answer ALL your questions on the
interiors of C and how everything is done "under the hood". Remember that
EVERYTHING inside the CPU and memory is just 0's and 1's. Learn assembly
language (GAS the GNU assembler), it's not that difficult. Also learn binary and
hexadecimal. There's tons of stuff on these subjects on the web and in books.
Using GDB you'll be able to examine how variables are laid out in memory
( x command), step assembly language statement by assembly language
statement through all the C functions, such as malloc(), fgets(), open(), etc.
Good Luck. I've learned alot using GDB and assembly.
Last edited by movl0x1; 05-16-2007 at 05:35 AM.
Look at disassembly to learn how the libc works? I don't think so. Far easier to just download the source and look at proper C code. glibc is open-source, you know.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Maybe he wanted to see it at runtime ?
@ zombiezparadize : Yeah. I do .. I have been through a course on assembly language.
@movl0x1 : Thanks for the help. Will look into it.
@zacs7: That is right.. I want to monitor the changes that occur when the program is being executed.
In the middle of difficulty, lies opportunity
Yes, it is easier to look at the Glibc source, but I like seeing how
stuff in C is done at the assembly level.
such as:
if (a == b)
In assembly this is similar to the following:
mov a, EAX <---------- That's how computers see everything (Well really in machine code, which is a step lower level)
mov b, EBX
cmp EAX, EBX
je somewhere (somewhere being a memory address)
That's fun to learn -- well, for me anyways
Last edited by movl0x1; 05-16-2007 at 09:06 AM.
Thanks for the help.This was new and fun
I actually started this thread with the intention of learning how the "heap" is used to allocate memory when I make a call to malloc and which part of the OS deals with these things. Can you guide me with that?
In the middle of difficulty, lies opportunity
malloc is in two parts.
Small memory allocations happen within a pool of memory managed by the malloc code itself in glibc. So allocating and freeing memory just involves moving a few pointers around (this is quick).
If the local pool runs out, then malloc makes a 'sbrk()' call to the OS (this is very slow by comparison) to request the OS to allocate more virtual memory to the process. The resulting block returned by the OS is added to the pool, and normal malloc operation takes over.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
@ SALEM :
OK! So, from your post, this is what i could glean:
glibc is allowed access to the actual memory. When there isn't enough space in the memory, srbk() is invoked to get more space through virtual memory which is essentially a memory image of a page that is stored on the disk and scheduled appropriately. That also explains why the allocation of new memory slots is slower..
Am I right??
This brings me to a few questions:
1. Is there a ceiling on the amount of memory space that the glibc can demand access to.
2. If the allocated pool of memory happens to be in the virtual memory, the overall performace of the application will also suffer right? Due to the occurence of page faults when the pages are not loaded in the momory.
I happened to find this link : http://developer.apple.com/documenta...n2/sbrk.2.html
Wherein he says : " The brk and sbrk functions are historical curiosities left over from earlier days before the advent of virtual memory management. "
But according to your prev post ,
> then malloc makes a 'sbrk()' call to the OS (this is very slow by comparison) to request the OS to allocate more >virtual memory to the process.
The following text also explains the working wrt the pages being added to the data segment in the actual memory.
Arent the two a little contradicting?
In the middle of difficulty, lies opportunity
Get the source code for glibc and read the malloc source code.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
And what is this "actual memory"?glibc is allowed access to the actual memory.
process can access the memory in its address space.
OS handles memory access request by moving the pages with the requested data from the swap file to the RAM as needed... And moving back pages of memory that are not accessed some time when space in the RAM is required for the other page...
The released page can be from the current process memory space or from some other process memory space.
When process asks access to some memory address - it has no way to know if the address is inside some page that is currently loaded to the RAM or stored on disk in the swap... Or even cached in the CPU cache...
When malloc asks OS about additional memory - it asks to add some page to the process memory space...
All the above is said about windows like OS
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
The malloc() thing has been discussed over and over here, so I'll talk about stack memory.
If a program wants to allocate 64 bytes for local variables (not with malloc() nor new), it decreases esp (stack pointer) by 64 and then those 64 bytes between the current esp location and the previous are used for those local variables. Before the function ends, program adds that amount back to esp. This is why local variables may contain random data before initialization.
Stack does many things. For example stacks holds the location where the function is called and return then uses stack to get back to the position where the function was called from.
There are many many interesting things about assembly. When writing programs in Assembly, you'll realize that even such low-level languages as C and C++ use a very limited structure, where you don't even have the control over registers.
Oh and if you're interested how Windows creates a process, I can find you some links which describe Windows kernel quite well.
Good reading about C runtime and malloc: http://www.kriha.de/krihaorg/docs/le...e/cruntime.pdf
Last edited by maxorator; 05-16-2007 at 02:13 PM.
"The Internet treats censorship as damage and routes around it." - John Gilmore
