This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB as a program analyzer - some thoughts


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]