From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
To: gdb@sources.redhat.com
Subject: gcc HEAD dwarf-2, synthetic methods no longer public, gdb confused
Date: Sun, 04 Jul 2004 11:19:00 -0000 [thread overview]
Message-ID: <20040704111919.73AEA4B104@berman.michael-chastain.com> (raw)
Here's my next problem with gcc HEAD -gdwarf-2. I suspect this is a bug
in gdb rather than gcc.
I've got a test program with a class, Alpha, that has a
compiler-synthesized assignment operator. That is, Alpha does not
declare or define an operator=, so the C++ compiler has to generate
one itself.
With the old gcc HEAD, the dwarf-2 info looks like this:
<2><f6b>: Abbrev Number: 21 (DW_TAG_subprogram)
DW_AT_sibling : <f98>
DW_AT_external : 1
DW_AT_name : (indirect string, offset: 0x9a3): operator=
DW_AT_MIPS_linkage_name: _ZN5AlphaaSERKS_
DW_AT_type : <fd1>
DW_AT_artificial : 1
DW_AT_declaration : 1
With the new gcc HEAD, the dwarf-2 info looks like this:
<2><f6b>: Abbrev Number: 21 (DW_TAG_subprogram)
DW_AT_sibling : <f86>
DW_AT_name : (indirect string, offset: 0x999): operator=
DW_AT_type : <fbd>
DW_AT_artificial : 1
DW_AT_declaration : 1
The difference is that DW_AT_external and DW_AT_MIPS_linkage_name
have gone away.
I narrowed this down to this one large patch:
2004-06-21 Mark Mitchell <mark@codesourcery.com>
...
* method.c (use_thunk): Use start_preparsed_function.
(synthesize_method): Likewise.
(implicitly_declare_fn): Build FUNCTION_DECLs, not declarators.
...
The difference is in implicitly_declare_fn. The old gcc HEAD
built a tree node with TREE_PUBLIC set, and the new gcc HEAD
does not. This might be an accidental change in the middle of
the big declarator change.
When gdb sees the new debug info with no DW_AT_external and no
DW_AT_MIPS_linkage_name, it gets a little strange with the type
information.
# gdb HEAD 2004-06-29
# gcc HEAD 2004-06-22 07:10:00 UTC
(gdb) ptype Alpha
type = class Alpha {
private:
int a_;
Empty empty_;
public:
Alpha(void);
}
# gdb HEAD 2004-06-29
# gcc HEAD 2004-06-22 07:20:00 UTC
(gdb) ptype Alpha
type = void (Alpha * const, const Alpha &)
Interestingly, this does not affect stabs+. It does affect dwarf-2.
Also, 'ptype class Alpha' works; it's only 'ptype Alpha' that is broken.
I can't find anything in TC++PL about the scope of synthesized methods.
But it seems reasonable to me that they no longer have DW_AT_external
and a DW_AT_MIPS_linkage_name.
I haven't looked inside dwarf2read.c yet. Somehow the change in debug
info is causing it to associate the name 'Alpha' with the synthesized
copy ctor rather than with the class. operator= has the changed debug
info, but gdb thinks that 'Alpha' is associated with the synthesized
copy ctor. Something strange is happening in the dwarf-2 reader.
This causes a FAIL in class2.exp on the "print (B *) abp" test, because
gdb thinks that "B" is not the name of s class. It probably causes some
of the other FAIL's I have here as well.
So my questions are:
... is this good dwarf-2 info?
... if so, can we fix the dwarf-2 reader to handle it?
... if not, i will file a gcc pr
Michael C
next reply other threads:[~2004-07-04 11:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-04 11:19 Michael Elizabeth Chastain [this message]
2004-07-04 14:52 ` Daniel Jacobowitz
2004-07-04 19:03 ` Mark Mitchell
2004-07-04 19:42 ` Mark Mitchell
2004-07-04 19:01 Michael Elizabeth Chastain
2004-07-05 23:45 Michael Elizabeth Chastain
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=20040704111919.73AEA4B104@berman.michael-chastain.com \
--to=mec.gnu@mindspring.com \
--cc=gdb@sources.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