Good ways to analyze a running c-program?

D

dspfun

I would like to analyze my running c-program.

What I would like to know for example is the range of the entire
address space of my running c-program (memory reserved for/by the
running program), starting address and sizes of text (code), stack,
heap, bss, constant data, linked in libraries, etc.

What are some good ways to extract this kind of information?

What (free) tools are the most common ones for displaying this kind of
information?

The main reason for this analysis is that I want to understand exactly
how my c-source code transforms to a running program and what memory
regions the program uses and for what the memory regions are used. An
example could be for example that I wanted to display all the constant
data (variables declared with the const modifier) of the running
program, is that possible?

BR!
 
J

jacob navia

dspfun a écrit :
I would like to analyze my running c-program.

What I would like to know for example is the range of the entire
address space of my running c-program (memory reserved for/by the
running program), starting address and sizes of text (code), stack,
heap, bss, constant data, linked in libraries, etc.

What are some good ways to extract this kind of information?

What (free) tools are the most common ones for displaying this kind of
information?

The main reason for this analysis is that I want to understand exactly
how my c-source code transforms to a running program and what memory
regions the program uses and for what the memory regions are used. An
example could be for example that I wanted to display all the constant
data (variables declared with the const modifier) of the running
program, is that possible?

BR!

So, you want to invest zero in software and get highly sophisticated
results...

This depends on your OS. If you run under linux you can try
the GNU profiler but last time I looked at it I do not remember
that it gave this kind of information. Other tools like "top",
can give you more info, but they are not really reliable. The man
page of top says for instance
TSIZE
The code size of the task. This gives strange values
for kernel processes and is broken for ELF processes.

Since all processes are ELF processes... this will not go very far.
But maybe this has improved in later versions, I really do not know.

Another possibility is tha you call yourself routines that give
this kind of info in your program and you call them at some
specific time, etc.

Under windows you can have several tools for doing that, but the only
really free one is the task manager, that will display the
memory/handles/paged/non paged memory/memory usage delta/
page faults/ and many other information.

Better tools are Intel's profiler, that is an excellent one
and will give you more detailed info. It costs around 500 US$.

If (under windows) you use the lcc-win32 debugger it will show you the stack
size of each thread but not when the process is running...


MMM... you give an idea. An oscilloscope-like display of memory usage
would be nice actually.
 
M

Mark McIntyre

dspfun a écrit :

So, you want to invest zero in software and get highly sophisticated
results...

No, he wants to use some free tools. You imply by the above that no
free software can be sophisticated, which is untrue as I'm sure you
know. There's even a compiler which is reputed to be fairly
sophisticated which is free.
This depends on your OS.

Agreed. The OP wold be better advised to ask in a group specialising
in his OS, as such tools will be highly OS-dependent.
can give you more info, but they are not really reliable. The man
page of top says for instance

(man pages are notorious for getting out of date mind you)
Under windows you can have several tools for doing that, but the only
really free one is the task manager, that will display the
memory/handles/paged/non paged memory/memory usage delta/
page faults/ and many other information.

FWIW there /are/ various free profiling and analysis tools for
Windows, eg at winternals.com
MMM... you give an idea. An oscilloscope-like display of memory usage
would be nice actually.

procexp.exe



--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
C

CBFalconer

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,576
Members
45,054
Latest member
LucyCarper

Latest Threads

Top