breakpoints and symbol examination problems

Hi all -

I'm having an issue with reaching breakpoints and examining
symbols in
my C++ code via gdb.  I can set breakpoints in my .cpp files
and
actually reach these, but if I put breakpoints in included
header
files (in template code), my program will run right through
the
breakpoints.

Additionally, I can't seem to examine any "stack"
variables once in
these template functions.  I can see member variables,
global
variables, and function parameters.

Does anyone have any suggestions for why this might happen
or things I
might try to get back normal functionality?

Thanks,
  Brian

On Mon, Mar 10, 2008 at 05:05:17PM -0700, Brian Budge
wrote:
> Hi all -
> 
> I'm having an issue with reaching breakpoints and
examining symbols in
> my C++ code via gdb.  I can set breakpoints in my .cpp
files and
> actually reach these, but if I put breakpoints in
included header
> files (in template code), my program will run right
through the
> breakpoints.

Try a snapshot of the current CVS HEAD or the 6.8 branch. 
This should
be fixed.

> Additionally, I can't seem to examine any
"stack" variables once in
> these template functions.  I can see member variables,
global
> variables, and function parameters.

This may be fixed, or it may be a compiler bug.  GCC is not
very good
about emitting local variable information in optimized
code.

-- 
Daniel Jacobowitz
CodeSourcery

On Mon, 2008-03-10 at 20:32 -0400, Daniel Jacobowitz wrote:
> On Mon, Mar 10, 2008 at 05:05:17PM -0700, Brian Budge
wrote:
> 
> > Additionally, I can't seem to examine any
"stack" variables once in
> > these template functions.  I can see member
variables, global
> > variables, and function parameters.
> 
> This may be fixed, or it may be a compiler bug.  GCC is
not very good
> about emitting local variable information in optimized
code.

Can you compile with -O0?

Actually, this is already with -O0... at least I think.  I'm
not
passing any optimization flags.  For debug symbols I'm
passing -ggdb.

I'll try the CVS current top of tree a bit later today.

Thanks,
  Brian

On Mon, Mar 10, 2008 at 5:52 PM, Michael Snyder
<msnyderspecifix.com> wrote:
> On Mon, 2008-03-10 at 20:32 -0400, Daniel Jacobowitz
wrote:
>  > On Mon, Mar 10, 2008 at 05:05:17PM -0700, Brian
Budge wrote:
>  >
>
> > > Additionally, I can't seem to examine any
"stack" variables once in
>  > > these template functions.  I can see member
variables, global
>  > > variables, and function parameters.
>  >
>  > This may be fixed, or it may be a compiler bug. 
GCC is not very good
>  > about emitting local variable information in
optimized code.
>
>  Can you compile with -O0?
>
>
>

Hi Michael, Daniel, all -

I built gdb from CVS gdb_6_8-branch, and indeed it fixed my
breakpoint
problem.  Unfortunately, I still can't examine local
variables.  I get
this interaction, for example:

207		vector< dopVertex<T> > tmpVerts;
(gdb)
208		vector< dopEdge > tmpEdges;
(gdb) p tmpVerts
No symbol "tmpVerts" in current context.

Needless to say, not being able to examine your local
variable makes
debugging fairly tricky ;)

So, one down, one to go... not too shabby.  Any more ideas?

Thanks,
  Brian

On Tue, Mar 11, 2008 at 8:24 AM, Brian Budge
<brian.budgegmail.com> wrote:
> Actually, this is already with -O0... at least I think.
 I'm not
>  passing any optimization flags.  For debug symbols I'm
passing -ggdb.
>
>  I'll try the CVS current top of tree a bit later
today.
>
>  Thanks,
>   Brian
>
>
>
>  On Mon, Mar 10, 2008 at 5:52 PM, Michael Snyder
<msnyderspecifix.com> wrote:
>  > On Mon, 2008-03-10 at 20:32 -0400, Daniel
Jacobowitz wrote:
>  >  > On Mon, Mar 10, 2008 at 05:05:17PM -0700,
Brian Budge wrote:
>  >  >
>  >
>  > > > Additionally, I can't seem to examine
any "stack" variables once in
>  >  > > these template functions.  I can see
member variables, global
>  >  > > variables, and function parameters.
>  >  >
>  >  > This may be fixed, or it may be a compiler
bug.  GCC is not very good
>  >  > about emitting local variable information
in optimized code.
>  >
>  >  Can you compile with -O0?
>  >
>  >
>  >
>

So here is a minimal repro case on my system:

foo.h
---------------------------------------------
template<typename joe>
struct Class1 {
    joe a;

    Class1(int b) : a(b) {}
};

template<typename joe>
struct Class2 {
    joe a;

    Class2(const Class1<joe> &rhs) {
        a = 0;
        for(int i = 0; i < 10; ++i) {
            a += rhs.a;
        }
    }
};

----------------------------------------------------
foo.cpp
--------------------------------------------------
#include <iostream>
#include "foo.h"

int main() {

    Class1<float> c1(15);

    Class2<float> c2(c1);

    std::cout << "value is " << c2.a
<< std::endl;

    return 0;
}
------------------------------------------------------------
--

I'm compiling foo.cpp with
> g++ -g foo.cpp

Here's my gdb session:

GNU gdb 6.7.90.20080311-cvs
Copyright Stuff (removed for brevity)
This GDB was configured as
"x86_64-unknown-linux-gnu"...
(gdb) b 8
Breakpoint 1 at 0x40093b: file foo.cpp, line 8.
(gdb) run
Starting program:
/home/budge/projects/rt_suite/apps/RtBatch/a.out

Breakpoint 1, main () at foo.cpp:8
8	    Class2<float> c2(c1);
(gdb) s
Class2 (this=0x7fff23e32c20, rhs=0x7fff23e32c30) at
foo.h:13
13	        a = 0;
(gdb) n
14	        for(int i = 0; i < 10; ++i) {
(gdb)
15	            a += rhs.a;
(gdb) p i
No symbol "i" in current context.


g++ reports version "Gentoo 4.1.1-r3".  I'm
running on amd64.

Hopefully that will help a little in figuring out what is
happening.

Thanks,
  Brian

On Tue, Mar 11, 2008 at 2:20 PM, Brian Budge
<brian.budgegmail.com> wrote:
> Hi Michael, Daniel, all -
>
>  I built gdb from CVS gdb_6_8-branch, and indeed it
fixed my breakpoint
>  problem.  Unfortunately, I still can't examine local
variables.  I get
>  this interaction, for example:
>
>  207             vector< dopVertex<T> >
tmpVerts;
>  (gdb)
>  208             vector< dopEdge > tmpEdges;
>  (gdb) p tmpVerts
>  No symbol "tmpVerts" in current context.
>
>  Needless to say, not being able to examine your local
variable makes
>  debugging fairly tricky ;)
>
>  So, one down, one to go... not too shabby.  Any more
ideas?
>
>  Thanks,
>   Brian
>
>
>
>  On Tue, Mar 11, 2008 at 8:24 AM, Brian Budge
<brian.budgegmail.com> wrote:
>  > Actually, this is already with -O0... at least I
think.  I'm not
>  >  passing any optimization flags.  For debug
symbols I'm passing -ggdb.
>  >
>  >  I'll try the CVS current top of tree a bit later
today.
>  >
>  >  Thanks,
>  >   Brian
>  >
>  >
>  >
>  >  On Mon, Mar 10, 2008 at 5:52 PM, Michael Snyder
<msnyderspecifix.com> wrote:
>  >  > On Mon, 2008-03-10 at 20:32 -0400, Daniel
Jacobowitz wrote:
>  >  >  > On Mon, Mar 10, 2008 at 05:05:17PM
-0700, Brian Budge wrote:
>  >  >  >
>  >  >
>  >  > > > Additionally, I can't seem to
examine any "stack" variables once in
>  >  >  > > these template functions.  I can
see member variables, global
>  >  >  > > variables, and function
parameters.
>  >  >  >
>  >  >  > This may be fixed, or it may be a
compiler bug.  GCC is not very good
>  >  >  > about emitting local variable
information in optimized code.
>  >  >
>  >  >  Can you compile with -O0?
>  >  >
>  >  >
>  >  >
>  >
>

Hi all -

This problem reproduces on my other system (opteron), which
is running 6.7.1.

How can I tell if this is lack of debug info from gcc or if
this is a
gdb problem?

Thanks,
  Brian



 On Tue, Mar 11, 2008 at 2:32 PM, Brian Budge
<brian.budgegmail.com> wrote:
> So here is a minimal repro case on my system:
>
> foo.h
> ---------------------------------------------
> template<typename joe>
> struct Class1 {
>    joe a;
>
>    Class1(int b) : a(b) {}
> };
>
> template<typename joe>
> struct Class2 {
>    joe a;
>
>    Class2(const Class1<joe> &rhs) {
>        a = 0;
>        for(int i = 0; i < 10; ++i) {
>            a += rhs.a;
>        }
>    }
> };
>
> ----------------------------------------------------
> foo.cpp
> --------------------------------------------------
> #include <iostream>
> #include "foo.h"
>
> int main() {
>
>    Class1<float> c1(15);
>
>    Class2<float> c2(c1);
>
>    std::cout << "value is " <<
c2.a << std::endl;
>
>    return 0;
> }
>
------------------------------------------------------------
--
>
> I'm compiling foo.cpp with
> > g++ -g foo.cpp
>
> Here's my gdb session:
>
> GNU gdb 6.7.90.20080311-cvs
> Copyright Stuff (removed for brevity)
> This GDB was configured as
"x86_64-unknown-linux-gnu"...
> (gdb) b 8
> Breakpoint 1 at 0x40093b: file foo.cpp, line 8.
> (gdb) run
> Starting program:
/home/budge/projects/rt_suite/apps/RtBatch/a.out
>
> Breakpoint 1, main () at foo.cpp:8
> 8           Class2<float> c2(c1);
> (gdb) s
> Class2 (this=0x7fff23e32c20, rhs=0x7fff23e32c30) at
foo.h:13
> 13              a = 0;
> (gdb) n
> 14              for(int i = 0; i < 10; ++i) {
> (gdb)
> 15                  a += rhs.a;
> (gdb) p i
> No symbol "i" in current context.
>
>
> g++ reports version "Gentoo 4.1.1-r3".  I'm
running on amd64.
>
> Hopefully that will help a little in figuring out what
is happening.
>
> Thanks,
>  Brian
>
>
>
>
> On Tue, Mar 11, 2008 at 2:20 PM, Brian Budge
<brian.budgegmail.com> wrote:
> > Hi Michael, Daniel, all -
> >
> >  I built gdb from CVS gdb_6_8-branch, and indeed
it fixed my breakpoint
> >  problem.  Unfortunately, I still can't examine
local variables.  I get
> >  this interaction, for example:
> >
> >  207             vector< dopVertex<T>
> tmpVerts;
> >  (gdb)
> >  208             vector< dopEdge >
tmpEdges;
> >  (gdb) p tmpVerts
> >  No symbol "tmpVerts" in current
context.
> >
> >  Needless to say, not being able to examine your
local variable makes
> >  debugging fairly tricky ;)
> >
> >  So, one down, one to go... not too shabby.  Any
more ideas?
> >
> >  Thanks,
> >   Brian
> >
> >
> >
> >  On Tue, Mar 11, 2008 at 8:24 AM, Brian Budge
<brian.budgegmail.com> wrote:
> >  > Actually, this is already with -O0... at
least I think.  I'm not
> >  >  passing any optimization flags.  For debug
symbols I'm passing -ggdb.
> >  >
> >  >  I'll try the CVS current top of tree a bit
later today.
> >  >
> >  >  Thanks,
> >  >   Brian
> >  >
> >  >
> >  >
> >  >  On Mon, Mar 10, 2008 at 5:52 PM, Michael
Snyder <msnyderspecifix.com> wrote:
> >  >  > On Mon, 2008-03-10 at 20:32 -0400,
Daniel Jacobowitz wrote:
> >  >  >  > On Mon, Mar 10, 2008 at
05:05:17PM -0700, Brian Budge wrote:
> >  >  >  >
> >  >  >
> >  >  > > > Additionally, I can't seem
to examine any "stack" variables once in
> >  >  >  > > these template functions. 
I can see member variables, global
> >  >  >  > > variables, and function
parameters.
> >  >  >  >
> >  >  >  > This may be fixed, or it may be
a compiler bug.  GCC is not very good
> >  >  >  > about emitting local variable
information in optimized code.
> >  >  >
> >  >  >  Can you compile with -O0?
> >  >  >
> >  >  >
> >  >  >
> >  >
> >
>

Lest anyone think this could be a 64 bit issue, this also
happens on
my i686 laptop with gdb 6.3.3.

Should I submit a bug to the gdb bug database?  Or could it
be this
bug?:  ht
tp://gcc.gnu.org/bugzilla/show_bug.cgi?id=27017.  Or is
it
another bug, but should be filed in gcc's bug database?

Just for fun, I have tested with many different gcc debug
flags
(dwarf-2, gdb, stabs, stabs+ all with various LEVELs), and
while gdb
doesn't always report the same error message when I try to
examine
locals, it always reports an error message.

Thanks,
  Brian

On Wed, Mar 12, 2008 at 1:14 PM, Brian Budge
<brian.budgegmail.com> wrote:
>
> Hi all -
>
>  This problem reproduces on my other system (opteron),
which is running 6.7.1.
>
>  How can I tell if this is lack of debug info from gcc
or if this is a
>  gdb problem?
>
>  Thanks,
>   Brian
>
>
>
>   On Tue, Mar 11, 2008 at 2:32 PM, Brian Budge
<brian.budgegmail.com> wrote:
>  > So here is a minimal repro case on my system:
>  >
>  > foo.h
>  > ---------------------------------------------
>  > template<typename joe>
>  > struct Class1 {
>  >    joe a;
>  >
>  >    Class1(int b) : a(b) {}
>  > };
>  >
>  > template<typename joe>
>  > struct Class2 {
>  >    joe a;
>  >
>  >    Class2(const Class1<joe> &rhs) {
>  >        a = 0;
>  >        for(int i = 0; i < 10; ++i) {
>  >            a += rhs.a;
>  >        }
>  >    }
>  > };
>  >
>  >
----------------------------------------------------
>  > foo.cpp
>  >
--------------------------------------------------
>  > #include <iostream>
>  > #include "foo.h"
>  >
>  > int main() {
>  >
>  >    Class1<float> c1(15);
>  >
>  >    Class2<float> c2(c1);
>  >
>  >    std::cout << "value is "
<< c2.a << std::endl;
>  >
>  >    return 0;
>  > }
>  >
------------------------------------------------------------
--
>  >
>  > I'm compiling foo.cpp with
>  > > g++ -g foo.cpp
>  >
>  > Here's my gdb session:
>  >
>  > GNU gdb 6.7.90.20080311-cvs
>  > Copyright Stuff (removed for brevity)
>  > This GDB was configured as
"x86_64-unknown-linux-gnu"...
>  > (gdb) b 8
>  > Breakpoint 1 at 0x40093b: file foo.cpp, line 8.
>  > (gdb) run
>  > Starting program:
/home/budge/projects/rt_suite/apps/RtBatch/a.out
>  >
>  > Breakpoint 1, main () at foo.cpp:8
>  > 8           Class2<float> c2(c1);
>  > (gdb) s
>  > Class2 (this=0x7fff23e32c20, rhs=0x7fff23e32c30) at foo.h:13
>  > 13              a = 0;
>  > (gdb) n
>  > 14              for(int i = 0; i < 10; ++i) {
>  > (gdb)
>  > 15                  a += rhs.a;
>  > (gdb) p i
>  > No symbol "i" in current context.
>  >
>  >
>  > g++ reports version "Gentoo 4.1.1-r3". 
I'm running on amd64.
>  >
>  > Hopefully that will help a little in figuring out
what is happening.
>  >
>  > Thanks,
>  >  Brian
>  >
>  >
>  >
>  >
>  > On Tue, Mar 11, 2008 at 2:20 PM, Brian Budge
<brian.budgegmail.com> wrote:
>  > > Hi Michael, Daniel, all -
>  > >
>  > >  I built gdb from CVS gdb_6_8-branch, and
indeed it fixed my breakpoint
>  > >  problem.  Unfortunately, I still can't
examine local variables.  I get
>  > >  this interaction, for example:
>  > >
>  > >  207             vector<
dopVertex<T> > tmpVerts;
>  > >  (gdb)
>  > >  208             vector< dopEdge >
tmpEdges;
>  > >  (gdb) p tmpVerts
>  > >  No symbol "tmpVerts" in current
context.
>  > >
>  > >  Needless to say, not being able to examine
your local variable makes
>  > >  debugging fairly tricky ;)
>  > >
>  > >  So, one down, one to go... not too shabby. 
Any more ideas?
>  > >
>  > >  Thanks,
>  > >   Brian
>  > >
>  > >
>  > >
>  > >  On Tue, Mar 11, 2008 at 8:24 AM, Brian
Budge <brian.budgegmail.com> wrote:
>  > >  > Actually, this is already with -O0...
at least I think.  I'm not
>  > >  >  passing any optimization flags.  For
debug symbols I'm passing -ggdb.
>  > >  >
>  > >  >  I'll try the CVS current top of tree
a bit later today.
>  > >  >
>  > >  >  Thanks,
>  > >  >   Brian
>  > >  >
>  > >  >
>  > >  >
>  > >  >  On Mon, Mar 10, 2008 at 5:52 PM,
Michael Snyder <msnyderspecifix.com> wrote:
>  > >  >  > On Mon, 2008-03-10 at 20:32
-0400, Daniel Jacobowitz wrote:
>  > >  >  >  > On Mon, Mar 10, 2008 at
05:05:17PM -0700, Brian Budge wrote:
>  > >  >  >  >
>  > >  >  >
>  > >  >  > > > Additionally, I can't
seem to examine any "stack" variables once in
>  > >  >  >  > > these template
functions.  I can see member variables, global
>  > >  >  >  > > variables, and
function parameters.
>  > >  >  >  >
>  > >  >  >  > This may be fixed, or it
may be a compiler bug.  GCC is not very good
>  > >  >  >  > about emitting local
variable information in optimized code.
>  > >  >  >
>  > >  >  >  Can you compile with -O0?
>  > >  >  >
>  > >  >  >
>  > >  >  >
>  > >  >
>  > >
>  >
>

On Wed, Mar 12, 2008 at 03:31:13PM -0700, Brian Budge
wrote:
> Should I submit a bug to the gdb bug database?  Or
could it be this
> bug?:  ht
tp://gcc.gnu.org/bugzilla/show_bug.cgi?id=27017.  Or is
it
> another bug, but should be filed in gcc's bug
database?

Whatever it is, it is clearly a GCC bug.

-- 
Daniel Jacobowitz
CodeSourcery