Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@redhat.com>
To: Alexandre Courbot <Alexandre.Courbot@lifl.fr>
Cc: gdb@sources.redhat.com
Subject: Re: GDB as a program analyzer - some thoughts
Date: Thu, 20 May 2004 03:11:00 -0000	[thread overview]
Message-ID: <vt2y8noypml.fsf@zenia.home> (raw)
In-Reply-To: <40AA23FD.6040103@lifl.fr>


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.


      parent reply	other threads:[~2004-05-20  3:11 UTC|newest]

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

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=vt2y8noypml.fsf@zenia.home \
    --to=jimb@redhat.com \
    --cc=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