Breakpoints in ctor and gcc 3.x

Breakpoints in ctor and gcc 3.x

[Cedric.Pillonel]

GCC doesn't stop on breakpoints in C++ constructors or destructors.
I'm using gcc 3.2 and gdb 5.2.1. I know it is a known bug with gcc 3.x.

This bug is old and I'm surprised that it still has not been fixed !!!
Is there any workaround?
When will it be fixed ? I think it is a serious one since you can't debug your ctor or dtor !

Thank you.

Cédric Pillonel

Re: Breakpoints in ctor and gcc 3.x

[Jim Blandy]

<Cedric.Pillonel@swisscom.com> writes:
> This bug is old and I'm surprised that it still has not been fixed
> !!!  Is there any workaround?  When will it be fixed ? I think it is
> a serious one since you can't debug your ctor or dtor !

The problem is that GCC emits two copies of a constructor: one that's
called to initialize a direct instance of the class (the "in charge"
constructor), and one to initialize the class's portion of an instance
of some derived class (the "not-in-charge" constructor).  They deal
with virtual base classes differently, and there may be some other
things.  But GDB only sets a breakpoint in one copy --- whichever one
appears first in the code.

At the moment, GDB assumes that each breakpoint set by the user can be
implemented by a single break instruction or hardware breakpoint.  To
handle breakpoints on constructors, you need to set two low-level
breakpoints --- one on the in-charge, and one on the not-in-charge.
This is going to be a lot of work to fix, and there were other, also
serious, C++ bugs folks decided to work on first.

Simply knowing the in-charge vs. not-in-charge distinction may help
out.  For example, if you're trying to debug the constructor for some
class's base class, but GDB is setting its breakpoint on the in-charge
constructor, you could try instantiating the base class directly, to
hit the breakpoint.  Or the reverse. 

You could try setting the breakpoint by raw address: use "disassemble"
and x/i to find the code address of the constructor instance you
actually want to debug, and use "break *EXPR" to set the breakpoint
there.

about class LOC_COMPUTED_ARG

[ankit thukral]

hi all,    
    this is about the address class of the symbols
(arguments or local symbols) which is LOC_COMPUTED.for
this class , the value of the symbol is calculated by
calling some function called locexpr_read_variable()
which is stored in as a function pointer as against
the class LOC_BASEREG in which the location of the
symbols is calculated using the "base register +
offset" approach. 
while debugging a process,i noticed that the argument
of some function had the address class LOC_BASEREG_ARG
while the same had LOC_COMPUTED_ARG in an older
version and newer version of GDB respectively.can
anyone tell me the reason for this shift i noticed? is
the class LOC_BASEREG_ARG becoming deprecated or is it
sort of buggy?
  


thanks in advance,
ankit.

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Re: Breakpoints in ctor and gcc 3.x

[Daniel Jacobowitz]

On Wed, Oct 01, 2003 at 08:37:37AM +0200, Cedric.Pillonel@swisscom.com wrote:
> GCC doesn't stop on breakpoints in C++ constructors or destructors.
> I'm using gcc 3.2 and gdb 5.2.1. I know it is a known bug with gcc 3.x.
> 
> This bug is old and I'm surprised that it still has not been fixed !!!
> Is there any workaround?
> When will it be fixed ? I think it is a serious one since you can't debug your ctor or dtor !

I have hopes to fix it for 6.1.  But like everything else in GDB, it
gets fixed when someone has both time and motivation to do it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: about class LOC_COMPUTED_ARG

[Daniel Jacobowitz]

On Wed, Oct 01, 2003 at 03:35:43AM -0700, ankit thukral wrote:
> hi all,    
>     this is about the address class of the symbols
> (arguments or local symbols) which is LOC_COMPUTED.for
> this class , the value of the symbol is calculated by
> calling some function called locexpr_read_variable()
> which is stored in as a function pointer as against
> the class LOC_BASEREG in which the location of the
> symbols is calculated using the "base register +
> offset" approach. 
> while debugging a process,i noticed that the argument
> of some function had the address class LOC_BASEREG_ARG
> while the same had LOC_COMPUTED_ARG in an older
> version and newer version of GDB respectively.can
> anyone tell me the reason for this shift i noticed? is
> the class LOC_BASEREG_ARG becoming deprecated or is it
> sort of buggy?
>   
> 
> 
> thanks in advance,

LOC_BASEREG_ARG was inadequate.  LOC_COMPUTED_ARG is a more powerful
mechanism, based on DWARF 2 location expressions.  Take a look at
http://www.eagercon.com/ if you want to find a copy of the
specification.

As I said in an earlier message, we don't have tracepoint support for
LOC_COMPUTED or LOC_COMPUTED_ARG - yet.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: about class LOC_COMPUTED_ARG

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> LOC_BASEREG_ARG was inadequate.  LOC_COMPUTED_ARG is a more powerful
> mechanism, based on DWARF 2 location expressions.  Take a look at
> http://www.eagercon.com/ if you want to find a copy of the
> specification.
> 
> As I said in an earlier message, we don't have tracepoint support for
> LOC_COMPUTED or LOC_COMPUTED_ARG - yet.

As a workaround until that's done, you might try compiling with
-gstabs+.  Only the Dwarf 2 reader generates LOC_COMPUTED and
LOC_COMPUTED_ARG; the stabs reader will generate LOC_BASEREG_ARG and
stuff like that, which ax-gdb.c knows how to handle.