From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: archer@sourceware.org
Cc: Sami Wagiaalla <swagiaal@redhat.com>, Keith Seitz <keiths@redhat.com>
Subject: Cross-CU C++ DIE references vs. mangling
Date: Wed, 10 Mar 2010 19:18:00 -0000 [thread overview]
Message-ID: <20100310191833.GA2816@host0.dyn.jankratochvil.net> (raw)
Hi,
wrt discussion on ignoring DW_AT_MIPS_linkage_name at all:
namespace S { extern int i; };
int *p = &S::i;
generates (4.5.0 20100310 (experimental)):
$ nm
U _ZN1S1iE
0000000000000000 D p
$ nm -C
U S::i
0000000000000000 D p
$ readelf -wi
# Simplified.
<1><4e>: Abbrev Number: 5 (DW_TAG_namespace)
<4f> DW_AT_name : S
<2><53>: Abbrev Number: 6 (DW_TAG_variable)
<54> DW_AT_name : i
<58> DW_AT_MIPS_linkage_name: (indirect string, offset: 0x32): _ZN1S1iE
<5c> DW_AT_type : <0x47>
<60> DW_AT_external : 1
<61> DW_AT_declaration : 1
So GDB has to know the "S::i"->"_ZN1S1iE" mangling rules if there would be no
DW_AT_MIPS_linkage_name. Just in this case GDB will find out "S::i" in the
defining CU (or shared library) and it can completely ignore this declaration.
So there is a countercase where GDB cannot ignore such declaration-only DIE
(and it is AFAIK the only requirement for GDB internal LOC_UNRESOLVED type):
namespace S
{
int f ()
{
int i = 42;
{
extern int i;
return i;
}
}
}
generates (4.5.0 20100310 (experimental)):
$ nm
0000000000000000 T _ZN1S1fEv
U _ZN1S1iE
$ nm -C
0000000000000000 T S::f()
U S::i
$ readelf -wi
# Grossly simplified.
<1><2d>: Abbrev Number: 2 (DW_TAG_namespace)
<2e> DW_AT_name : S
<2><36>: Abbrev Number: 3 (DW_TAG_subprogram)
<37> DW_AT_external : 1
<38> DW_AT_name : f
<3c> DW_AT_MIPS_linkage_name: (indirect string, offset: 0x49): _ZN1S1fEv
<61> DW_AT_low_pc : 0x0
<69> DW_AT_high_pc : 0x13
<71> DW_AT_frame_base : 0x0 (location list)
<3><75>: Abbrev Number: 7 (DW_TAG_lexical_block)
<76> DW_AT_low_pc : 0x4
<7e> DW_AT_high_pc : 0x11
<4><86>: Abbrev Number: 8 (DW_TAG_variable)
<87> DW_AT_name : i
<8f> DW_AT_location : 2 byte block: 91 6c (DW_OP_fbreg: -20)
<4><92>: Abbrev Number: 9 (DW_TAG_lexical_block)
<93> DW_AT_low_pc : 0xb
<9b> DW_AT_high_pc : 0x11
<2><45>: Abbrev Number: 4 (DW_TAG_variable)
<46> DW_AT_name : i
<4a> DW_AT_MIPS_linkage_name: (indirect string, offset: 0x40): _ZN1S1iE
<52> DW_AT_external : 1
<53> DW_AT_declaration : 1
This dump is wrong, last DIE should have been <5><45>: ... = new PR debug/43325.
This is just a C++ variant of the testcase gdb.dwarf2/dw2-unresolved*.
I was suggesting to use DW_FORM_ref_addr referencing global artifical symbols
like <prefix>.<file-designator>.<gid-number>.<die-number> (as described by
DWARF). But I see now such reference is mostly just a different form of
something like DW_AT_MIPS_linkage_name so it may be no win. Roland McGrath
said on it:
(2009-12-11 23:20:32) keiths: Right now for C++, minimal symbols are used to resolve all symbol references to addresses. (Unlike in C, where the actual symtab is used.) That's a side affect of how gdb's C++ support has been written. [This is all fixed by my dwarf2_physname patch.]
(2009-12-11 23:35:36) jkratoch: and minimal symbols are used for referencing DW_AT_location from different CU. I would think such DW_AT_location should exist in the non-defining CU with a relocation record - so that DWARF has no dependency on ELF.
(2009-12-11 23:36:32) roland: but then it would have a different hairy kind of dependency on ELF, i.e. relocation
(2009-12-11 23:41:15) jkratoch: OK, that makes sense, thanks, such a longterm issue I had.
Regards,
Jan
next reply other threads:[~2010-03-10 19:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-10 19:18 Jan Kratochvil [this message]
2010-03-10 19:32 ` Jan Kratochvil
2010-03-11 6:03 ` Roland McGrath
2010-04-12 18:51 ` Sami Wagiaalla
2010-04-27 8:50 ` Roland McGrath
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=20100310191833.GA2816@host0.dyn.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=archer@sourceware.org \
--cc=keiths@redhat.com \
--cc=swagiaal@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).