This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: gdb 6.3 C++ breakpoint in constructor/destructor patch
- From: Daniel Jacobowitz <drow at false dot org>
- To: Thomas Maier <balagi at justmail dot de>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sun, 1 May 2005 15:05:32 -0400
- Subject: Re: gdb 6.3 C++ breakpoint in constructor/destructor patch
- References: <opsp30fyk1iudtyh@aee20.a.pppool.de>
On Sun, May 01, 2005 at 08:32:12PM +0200, Thomas Maier wrote:
> Hello,
>
> I want to supply a patch for the released gdb 6.3, that fixes partially
> the gdb bugs
>
> gdb/1091: Constructor breakpoints ignored
> gdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set
> breakpoints
>
> I was really confused, why my programs to not stop at the breakpoint in
> constructor/destructors. Now i know, it is not the fault of my programs ;)
> Since this anoying problem seems to be in gdb since the gcc 3.x release, i
> guess, no one else a) has this problem (i don't believe so) or b) will not
> fix it. So i did it ;)
>
> This modification is only made for commands like "break
> [source]:<lineno>". For C++ constructors and destructors, the patch
> creates more than one breakpoint at the source at lineno, but each
> generated breakpoint will have another address!
>
> NOTE: this is only a simple "hack". I have spent only one day to get into
> gdb source code and do the modification.
> It would be better, to create only one breakpoint in such C++ constructors
> and destructors and assign multiple addresses to it. But this needs a huge
> modification of gdb, i guess ;)
This is not a very useful change, because it only handles the case
where everything at a particular line is in the same symtab. Often
this will not be the case.
If you take a look at the archives for the list, you will find a lot of
discussion on this subject - as well as a prototype patch I posted
earlier this year. That patch may be good enough for your needs, since
it handles the file:lineno case. But it isn't done yet, and I haven't
had time to go back to it yet.
--
Daniel Jacobowitz
CodeSourcery, LLC