From: David Carlton <carlton@kealia.com>
To: gdb-patches@sources.redhat.com
Cc: Elena Zannoni <ezannoni@redhat.com>, Daniel Jacobowitz <drow@mvista.com>
Subject: [rfa] classes, partial symtabs, and DW_AT_specification
Date: Sat, 24 Jan 2004 00:41:00 -0000 [thread overview]
Message-ID: <m34qump4a7.fsf@coconut.kealia.com> (raw)
This is another DW_AT_specification problem that crops up with GCC
3.4. The picture is this:
namespace N {
class C {
// definition of N::C
};
}
gives rise to this in GCC 3.4:
1: DW_TAG_compile_unit
2: DW_TAG_namespace // N
3: DW_TAG_structure_scope // declaration for N::C
4: DW_TAG_structure_scope // definition for N::C
DW_AT_specification => points to die #3.
When building the partial symbol table for this file, we look for
definitions of classes; but, when we see the definition for N::C, the
only way we know from the debug info that we're within namespace N is
by following DW_AT_specification. Which we can't do with our
psymtabs.
This is a serious design problem with our psymtab structure, which
we've known about for a while. Either we need to add into it a fast
way to follow DW_AT_specification links _and_ then figure out the
parent of the die at the other end, or we need help from the compiler,
or something. In any event, any correct solution would be a major
undertaking; the best way to deal with the situation for now is to use
demangled names when we run into this situation, just like we would if
the compiler weren't generating DW_TAG_namespace at all.
Tested on i686-pc-linux-gnu, DWARF-2, 4 different GCC variants; no
regressions, and on GCC 3.4 two tests in rtti.exp went from {K}FAIL to
PASS.
OK to commit? I guess I need symtab approval, though Daniel should
feel free to chime in as well. :-) And at some point we really need to
develop a plan of attack for DWARF-2 partial symbols - what
improvements can we do without GCC's help, what help do we want from
GCC?
David Carlton
carlton@kealia.com
2004-01-23 David Carlton <carlton@kealia.com>
* dwarf2read.c (add_partial_structure): Use demangled name if
namespace equals "".
Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.124
diff -u -p -r1.124 dwarf2read.c
--- dwarf2read.c 23 Jan 2004 22:41:28 -0000 1.124
+++ dwarf2read.c 24 Jan 2004 00:05:37 -0000
@@ -1660,12 +1660,12 @@ add_partial_structure (struct partial_di
char *actual_class_name = NULL;
if (cu_language == language_cplus
- && namespace == NULL
+ && (namespace == NULL || namespace[0] == '\0')
&& struct_pdi->name != NULL
&& struct_pdi->has_children)
{
- /* We don't have namespace debugging information, so see if we
- can figure out if this structure lives in a namespace. Look
+ /* See if we can figure out if the class lives in a namespace
+ (or is nested within another class.) We do this by looking
for a member function; its demangled name will contain
namespace info, if there is any. */
@@ -1674,6 +1674,21 @@ add_partial_structure (struct partial_di
frequently doesn't give the same name as the debug info. We
could fix this by only using the demangled name to get the
prefix (but see comment in read_structure_scope). */
+
+ /* FIXME: carlton/2004-01-23: If NAMESPACE equals "", we have
+ the appropriate debug information, so it would be nice to be
+ able to avoid this hack. But NAMESPACE may not be the
+ namespace where this class was defined: NAMESPACE reflects
+ where STRUCT_PDI occurs in the tree of dies, but because of
+ DW_AT_specification, that may not actually tell us where the
+ class is defined. (See the comment in read_func_scope for an
+ example of how this could occur.)
+
+ Unfortunately, our current partial symtab data structures are
+ completely unable to deal with DW_AT_specification. So, for
+ now, the best thing to do is to get nesting information from
+ places other than the tree structure of dies if there's any
+ chance that a DW_AT_specification is involved. :-( */
char *next_child = info_ptr;
next reply other threads:[~2004-01-24 0:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-24 0:41 David Carlton [this message]
2004-01-25 17:00 ` Daniel Jacobowitz
2004-01-28 18:51 ` David Carlton
2004-01-28 19:59 ` Daniel Jacobowitz
2004-01-28 17:11 ` Elena Zannoni
2004-01-28 18:44 ` David Carlton
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=m34qump4a7.fsf@coconut.kealia.com \
--to=carlton@kealia.com \
--cc=drow@mvista.com \
--cc=ezannoni@redhat.com \
--cc=gdb-patches@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