Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Alexandre Courbot <Alexandre.Courbot@lifl.fr>
To: gdb@sources.redhat.com
Subject: GDB as a program analyzer - some thoughts
Date: Tue, 18 May 2004 14:57:00 -0000	[thread overview]
Message-ID: <40AA23FD.6040103@lifl.fr> (raw)

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


             reply	other threads:[~2004-05-18 14:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-18 14:57 Alexandre Courbot [this message]
2004-05-18 15:49 ` Ramana Radhakrishnan
2004-05-18 17:04 ` Chris January
2004-05-20  3:11 ` Jim Blandy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40AA23FD.6040103@lifl.fr \
    --to=alexandre.courbot@lifl.fr \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox