GDB as a program analyzer - some thoughts

GDB as a program analyzer - some thoughts

[Alexandre Courbot]

This post deals about using GDB for non-debugging purposes, I hope it's 
not offtopic. I'm also hoping to find some people interested in the same 
matters than I to discuss about how GDB could be improved for analysis 
purposes.

My few posts here have been basically about it. GDB is great to extract 
datas out of a program and output them to a file. It's very different to 
gprof - for instance, it's useful to graphically measure the efficiency 
of one memory manager against another, by placing breakpoints at memory 
allocation functions and recording the amount of memory used there. The 
recorded datas can then proove that, with some strategy, we saved a few 
garbage collections and therefore gained speed.

This is of course nothing you can't do with printfs enclosed inside 
#ifdef DEBUGs, but the advantage is that GDB allows you to do it in a 
non-intrusive and much more flexible way. I'm surprised that I haven't 
found a solutions dedicated to that - and so far, gdb is by far the best 
solution I've found. Writing a gdb script + the corresponding gnuplot 
script results in easy to get graphes of whatever you want in your program.

If people are interested in it, I can post some of the scripts I'm using 
with their result. I can also write a tutorial page on that topic.

I have some non-elegant bits in my scripts however. They mainly concern 
breakpoints. Since the breakpoints are set into gdb scripts, it's better 
if they reference symbols like function names instead of 
file:line_number pairs. The line of the breakpoint might move in future 
code modifications, and the gdb script won't be updated accordingly. 
Unfortunately, breaking at the very beginning of the function you are 
interested doesn't give you the data that has been computed inside.

So, I wonder if some breakpoint settings would be implementable with gdb 
(or if they can already be expressed and I missed them):
- Setting a breakpoint at the returning of a function
- Setting a breakpoint at some fixed point of a function (for instance, 
a C label)
- Any other breakpoint setting that is not line-number based and would 
support source modification

Would these features be desirable? Would they not?

Alex.
-- 
Alexandre Courbot - PhD student
RD2P/LIFL
http://www.lifl.fr/~courbot

Re: GDB as a program analyzer - some thoughts

[Ramana Radhakrishnan]

Hi Alexandre,

> This post deals about using GDB for non-debugging purposes, I hope 
> it's not offtopic. I'm also hoping to find some people interested in 
> the same matters than I to discuss about how GDB could be improved for 
> analysis purposes.
>
> My few posts here have been basically about it. GDB is great to 
> extract datas out of a program and output them to a file. It's very 
> different to gprof - for instance, it's useful to graphically measure 
> the efficiency of one memory manager against another, by placing 
> breakpoints at memory allocation functions and recording the amount of 
> memory used there. The recorded datas can then proove that, with some 
> strategy, we saved a few garbage collections and therefore gained speed.
>
> This is of course nothing you can't do with printfs enclosed inside 
> #ifdef DEBUGs, but the advantage is that GDB allows you to do it in a 
> non-intrusive and much more flexible way. 

Well non-intrusive / rather less intrusive :-) ? There is still the 
overhead of a ptrace call in case of native debugging. in such cases ? 
Flexible yes  .

> I'm surprised that I haven't found a solutions dedicated to that - and 
> so far, gdb is by far the best solution I've found. Writing a gdb 
> script + the corresponding gnuplot script results in easy to get 
> graphes of whatever you want in your program.
>
> If people are interested in it, I can post some of the scripts I'm 
> using with their result. I can also write a tutorial page on that topic.
>
> I have some non-elegant bits in my scripts however. They mainly 
> concern breakpoints. Since the breakpoints are set into gdb scripts, 
> it's better if they reference symbols like function names instead of 
> file:line_number pairs. The line of the breakpoint might move in 
> future code modifications, and the gdb script won't be updated 
> accordingly. Unfortunately, breaking at the very beginning of the 
> function you are interested doesn't give you the data that has been 
> computed inside.
>
> So, I wonder if some breakpoint settings would be implementable with 
> gdb (or if they can already be expressed and I missed them):
> - Setting a breakpoint at the returning of a function

Could be done by maybe adding  a pre-finish command to gdb  ? Though 
ofcourse in modern toolchains since the size of a function is present a 
hack might be to write a script using
using objdump / awk to generate a gdb script per function to put 
breakpoints at all possible return instructions ?

 There does not seem to be  a pre-finish function. finish runs through 
the current activation record and returns .What you seem to want is for 
gdb to stop just before the function returns
so that the data can be collected.


> - Setting a breakpoint at some fixed point of a function (for 
> instance, a C label)

> - Any other breakpoint setting that is not line-number based and would 
> support source modification

In continuation with my fancy for awk , grep and objdump maybe generate 
your script with respect to the functions that you are interested in ?
 objdump -x executable; grep for the symbol, get the address and then 
generate the script with the correct address. Ofcourse might sound like 
overkill for something so simple ?

>



cheers
Ramana

RE: GDB as a program analyzer - some thoughts

[Chris January]

> This post deals about using GDB for non-debugging purposes, I hope it's
> not offtopic. I'm also hoping to find some people interested in the same
> matters than I to discuss about how GDB could be improved for analysis
> purposes.

See:
http://www.argreenhouse.com/papers/hira/spe93.pdf
for a program trace/dynamic analysis tool built on top of gdb and gcc.

I'm currently working on a program tracing tool for i386 that uses Valgrind
and GDB for my final year project. It should allow you to query program
traces using SQL.
Example:
set filter {x>5}
history
or some similar syntax.
would show you all the places when (and where) the variable x (when in
scope) had a value greater than 5.
Feel free to mail me off list if you want to discuss this kind of thing any
further.

Regards,
Chris

Re: GDB as a program analyzer - some thoughts

[Jim Blandy]

Alexandre Courbot <Alexandre.Courbot@lifl.fr> writes:
> So, I wonder if some breakpoint settings would be implementable with
> gdb (or if they can already be expressed and I missed them):
> - Setting a breakpoint at the returning of a function

I think this would be a great feature.  Stan Shebs and I looked into
implementing a long time ago, and decided that it couldn't be done
without further help from the compiler.  The first problem is that
it's hard to decide where to put the breakpoint: the function return
code could be replicated many times in the function's body.  But even
then, you need to set the breakpoint before the code that restores the
caller's registers and frame pointer, or else you won't be able to
find your local variables.

So this is harder than it looks.  I think it might need help from the
compiler.

> - Setting a breakpoint at some fixed point of a function (for
> instance, a C label)

This would be nice, too.  At the moment, GCC does produce debugging
information for labels when the Dwarf 2 debug format is used, but
GDB's support for them is incomplete.

> - Any other breakpoint setting that is not line-number based and would
> support source modification

GDB's 'search' command sets the convenience variable $_ to the number
of the matching line.  So you can do stuff like this:

(gdb) search marker
6         i--;  /* marker */
(gdb) break $_
Breakpoint 1 at 0x804837b: file label.c, line 6.
(gdb)

I think that's your best bet at the moment.