From: "Brian Budge" <brian.budge@gmail.com>
To: gdb@sourceware.org
Subject: Re: breakpoints and symbol examination problems
Date: Wed, 12 Mar 2008 23:02:00 -0000 [thread overview]
Message-ID: <5b7094580803121531l1ecb2cdbyb917c98683313e0e@mail.gmail.com> (raw)
In-Reply-To: <5b7094580803121314t1e869571lf94029facedf0498@mail.gmail.com>
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?: http://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.budge@gmail.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.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?
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
next prev parent reply other threads:[~2008-03-12 22:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-11 0:33 Brian Budge
2008-03-11 0:37 ` Daniel Jacobowitz
2008-03-11 9:53 ` Michael Snyder
2008-03-11 17:45 ` Brian Budge
2008-03-11 21:32 ` Brian Budge
2008-03-12 9:14 ` Brian Budge
[not found] ` <5b7094580803121306v7da4475dy5f91be7c7d8753e0@mail.gmail.com>
2008-03-12 22:31 ` Fwd: " Brian Budge
2008-03-12 23:02 ` Brian Budge [this message]
2008-03-13 3:56 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5b7094580803121531l1ecb2cdbyb917c98683313e0e@mail.gmail.com \
--to=brian.budge@gmail.com \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox