This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Fwd: breakpoints and symbol examination problems
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.budge@gmail.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.budge@gmail.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.budge@gmail.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 <msnyder@specifix.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?
> > > >
> > > >
> > > >
> > >
> >
>