This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] dwarf2_physname FINAL
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: keiths at redhat dot com (Keith Seitz)
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 23 Mar 2010 21:24:52 +0100 (CET)
- Subject: Re: [RFA] dwarf2_physname FINAL
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