From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: keiths@redhat.com (Keith Seitz)
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA] dwarf2_physname FINAL
Date: Tue, 23 Mar 2010 20:25:00 -0000 [thread overview]
Message-ID: <201003232024.o2NKOqIZ019784@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <4B903926.7070303@redhat.com> from "Keith Seitz" at Mar 04, 2010 02:50:14 PM
Keith Seitz wrote:
> There is an apparent regression in jprint.exp. Printing static class
> variables (java only) is "broken." This is a gcc bug (gcc/43260): we
> don't get any location info from gcc about where the static variable
> lives, so we report it as "optimized out." NOTE: This "works" on CVS
> HEAD because we fallback to using the linkage name (from
> DW_AT_MIPS_linkage_name) to search the minimal symbol table, using that
> to grab the address of the variable. Obviously we won't be able to do
> that any more.
Would it be possible to KFAIL that?
I'm also seeing a second Java-related regression:
FAIL: gdb.java/jmisc.exp: ptype jmisc
This is because "ptype jmisc" now shows:
type = class jmisc extends java.lang.Object {
void main(java.lang.String[])void;
void <init>(void)void;
}
instead of
type = class jmisc extends java.lang.Object {
void main(java.lang.String[])void;
jmisc();
}
This is apparently caused by Java using DW_AT_MIPS_linkage_name to hide
the <init> magic name for the constructor:
<2><223>: Abbrev Number: 6 (DW_TAG_subprogram)
DW_AT_external : 1
DW_AT_name : <init>
DW_AT_MIPS_linkage_name: _ZN5jmiscC1Ev
DW_AT_artificial : 1
DW_AT_declaration : 1
Is this to be expected? Or should this be handled by the new code
somewhere?
Also, I'm now seeing three failures in the new cpexprs.exp:
FAIL: gdb.cp/cpexprs.exp: list base::overload(void)
FAIL: gdb.cp/cpexprs.exp: setting breakpoint at base::overload(void)
FAIL: gdb.cp/cpexprs.exp: continue to base::overload(void)
apparently related to whether "const" needs to be specified when
identifying an overloaded method. I seem to recall some reference
to this problem in one of the dwarf2_physname threads -- is this
still an expected problem with the final patch?
This is all on a RHEL5.4 with the system GCC 4.1.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next prev parent reply other threads:[~2010-03-23 20:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-04 22:52 Keith Seitz
2010-03-05 21:54 ` Tom Tromey
2010-03-05 22:12 ` Keith Seitz
2010-03-08 6:18 ` Joel Brobecker
2010-03-09 18:10 ` Keith Seitz
2010-03-10 8:11 ` [commit/dwarf2/Ada] Adjust handling of Ada DIEs after dwarf2_physname patch Joel Brobecker
2010-03-23 20:25 ` Ulrich Weigand [this message]
2010-03-24 20:24 ` [RFA] dwarf2_physname FINAL Keith Seitz
2010-03-25 10:21 ` Ulrich Weigand
2010-03-25 18:31 ` [RFA] Java DWARF fixes (was Re: [RFA] dwarf2_physname FINAL) Keith Seitz
2010-03-25 20:05 ` [RFA] Java DWARF fixes Tom Tromey
2010-03-25 22:14 ` Keith Seitz
2010-03-26 16:48 ` Ulrich Weigand
2010-03-26 16:54 ` Keith Seitz
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=201003232024.o2NKOqIZ019784@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=keiths@redhat.com \
/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