public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug c++/15203] GDB can't find static variable declared locally Date: Mon, 18 Mar 2013 09:20:00 -0000 [thread overview] Message-ID: <bug-15203-4717-tvLF1bmbDk@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-15203-4717@http.sourceware.org/bugzilla/> http://sourceware.org/bugzilla/show_bug.cgi?id=15203 --- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> 2013-03-18 09:20:22 UTC --- CVSROOT: /cvs/src Module name: src Branch: gdb_7_6-branch Changes by: sergiodj@sourceware.org 2013-03-18 09:20:07 Modified files: gdb : ChangeLog cp-namespace.c elfread.c gdb/testsuite : ChangeLog gdb/testsuite/gdb.cp: m-static.cc m-static.exp Log message: From: Sergio Durigan Junior <sergiodj@redhat.com> Subject: [PATCH] Fix for PR c++/15203 and PR c++/15210 Date: Sat, 09 Mar 2013 02:50:49 -0300 (5 days, 4 hours, 57 minutes ago) Message-ID: <m3a9qdnmti.fsf@redhat.com> Hi, This bug was reported internally at our Bugzilla, along with a proposed fix. After talking to Keith about it, he investigated and came up with another patch needed to really fix the issue on CVS HEAD. The first part of the fix is the patch to cp-namespace.c. It handles the case when we are accessing a static variable inside a function (inside a class) by the full linespec (is it right, Keith?). E.g.: class foo { public: int bar() { static int var = 0; } }; And then, printing the value of `var': (gdb) print 'foo::bar()::var' GDB would fall in an internal_error: gdb/cp-namespace.c:816: internal-error: cp_lookup_nested_symbol called on a non-aggregate type. This is because `cp_lookup_nested_symbol' is not handling the case when TYPE_CODE is either _FUNC or _METHOD. This patch fixes it by returning NULL in this case. The second part of the fix is the patch to elfread.c. It is needed because the BSF_GNU_UNIQUE flag was added to some symbols in <http://sourceware.org/ml/binutils/2009-06/msg00016.html>. Because of that, (still) the command: (gdb) print 'foo::bar()::var' where `var' is a static variable returns: "No symbol "foo::bar()::var" in current context." So with the second patch applied the command finally DTRT: (gdb) print 'foo::bar()::var' $1 = 0 This may not be the ideal solution, according to Keith it would be good to implement productions on c-exp.y in order to recognize CLASS::FUNCTION::VARIABLE, but it is a solution which works with what we have today. I regtested it in Fedora 17 x86_64 with -m64 and -m32, including gdbserver, without regressions. gdb/: 2013-03-14 Keith Seitz <keiths@redhat.com> Alan Matsuoka <alanm@redhat.com> PR c++/15203 PR c++/15210 * cp-namespace.c (cp_lookup_nested_symbol): Handle TYPE_CODE_FUNC and TYPE_CODE_METHOD. * elfread.c (elf_symtab_read): Handle BSF_GNU_UNIQUE for certain symbols. gdb/testsuite/: 2013-03-14 Sergio Durigan Junior <sergiodj@redhat.com> PR c++/15203 PR c++/15210 * gdb.cp/m-static.cc (keepalive_int): New function. (gnu_obj_1::method): New variable `sintvar', call `keepalive_int'. * gdb.cp/m-static.exp: New test for `sintvar'. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&only_with_tag=gdb_7_6-branch&r1=1.15260.2.6&r2=1.15260.2.7 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/cp-namespace.c.diff?cvsroot=src&only_with_tag=gdb_7_6-branch&r1=1.65&r2=1.65.2.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/elfread.c.diff?cvsroot=src&only_with_tag=gdb_7_6-branch&r1=1.148&r2=1.148.2.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/ChangeLog.diff?cvsroot=src&only_with_tag=gdb_7_6-branch&r1=1.3580.2.1&r2=1.3580.2.2 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.cp/m-static.cc.diff?cvsroot=src&only_with_tag=gdb_7_6-branch&r1=1.6&r2=1.6.2.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.cp/m-static.exp.diff?cvsroot=src&only_with_tag=gdb_7_6-branch&r1=1.21&r2=1.21.2.1 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
prev parent reply other threads:[~2013-03-18 9:20 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-02-27 1:01 [Bug c++/15203] New: " sergiodj at redhat dot com 2013-02-27 18:18 ` [Bug c++/15203] " sergiodj at redhat dot com 2013-02-27 18:45 ` sergiodj at redhat dot com 2013-03-14 11:13 ` cvs-commit at gcc dot gnu.org 2013-03-14 11:17 ` sergiodj at redhat dot com 2013-03-18 9:20 ` cvs-commit at gcc dot gnu.org [this message]
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=bug-15203-4717-tvLF1bmbDk@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@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: linkBe 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; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).