Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Manoj Iyer <manjo@austin.ibm.com>
Cc: gdb-patches@sources.redhat.com, Elena Zannoni <ezannoni@redhat.com>
Subject: Re: [RFC] Dont skip DW_TAG_member in load_partial_dies()
Date: Wed, 16 Feb 2005 01:09:00 -0000	[thread overview]
Message-ID: <20050215232018.GB8631@nevyn.them.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0502151434470.29945@lazy>

On Tue, Feb 15, 2005 at 03:06:57PM -0600, Manoj Iyer wrote:
> 
> GDB prints internal error with C++ application produced by XLC.

Many of the tests in the GDB testsuite already will probably produce
this error, if you want to try running the testsuite with xlC.  It
probably won't be easy, though.

I'm copying this to Elena, since she is the maintainer of the DWARF-2
reader.  Your patch looks right to me.  In fact, I've been working on
running the GDB testsuite using ARM's compiler today, and I have a
patch that looks exactly like this in my working directory :-)

> When the above testcase is compiled -m64 by XLC, GDB generates an internal
> error:
> 
> "internal-error: could not find partial DIE in cache"
> 
> GCC creates a DWARF TAG for "a" as DW_TAG_variable and XLC creates
> DW_TAG_member. GDB throws away TAGS that it find as uninteresting. In this
> case DW_TAG_member. (this is in dwarf2read.c function:
> load_partial_dies(). )
> 
> GCC created DWARF information
> -------------------------------
>  <2><102>: Abbrev Number: 13 (DW_TAG_variable)
>      DW_AT_name        : a
>      DW_AT_decl_file   : 1
>      DW_AT_decl_line   : 13
>      DW_AT_MIPS_linkage_name: _ZN1XIiE1aE
>      DW_AT_type        : <d5>
>      DW_AT_external    : 1
>      DW_AT_declaration : 1
> 
> XLC created DWARF information
> ------------------------------
>  <2><96>: Abbrev Number: 5 (DW_TAG_member)
>      DW_AT_name        : a
>      DW_AT_accessibility: 1     (public)
>      DW_AT_declaration : 1
>      DW_AT_type        : <78>
> 
> 
> GCC in this case is producing wrong information. According to DWARF
> spec:
> 
> " If the variable entry represents the defining declaration for a C++
> static data member of a structure, class or union, the entry has a
> DW_AT_specification attribute, whose value is a reference to the debugging
> information entry representing the declaration of this data member. The
> referenced entry has the tag DW_TAG_member and will be a child of some
> class, structure or union type entry. "
> 
> So I think GDB needs to handle the DW_TAG_member and not skip it, when
> dealing with  C++.
> 
> Here is a patch to GDB that will fix this problem
> 
> ================ Patch to gdb ==================
> 2005-02-15  Manoj Iyer  <manjo@austin.ibm.com>
> 
>         * dwarf2read.c (load_partial_dies): Save DIE with tag
>         DW_TAG_member, generated by XLC when compiling C++ application.
> 
> diff -Naur ./old/src/gdb/dwarf2read.c ./new/src/gdb/dwarf2read.c
> --- ./old/src/gdb/dwarf2read.c  2005-02-15 11:13:05.000000000 -0600
> +++ ./new/src/gdb/dwarf2read.c  2005-02-22 10:24:08.000000000 -0600
> @@ -5167,7 +5167,8 @@
>           && abbrev->tag != DW_TAG_enumerator
>           && abbrev->tag != DW_TAG_subprogram
>           && abbrev->tag != DW_TAG_variable
> -         && abbrev->tag != DW_TAG_namespace)
> +         && abbrev->tag != DW_TAG_namespace
> +         && abbrev->tag != DW_TAG_member)
>         {
>           /* Otherwise we skip to the next sibling, if any.  */
>           info_ptr = skip_one_die (info_ptr + bytes_read, abbrev, cu);
> 
> ========================= END PATCH ======================
> 
> 
> ok to commit?
> 
> Thanks
> -----
> manjo
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> + Cogito ergo sum                                                          +
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 

-- 
Daniel Jacobowitz
CodeSourcery, LLC


  reply	other threads:[~2005-02-15 23:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-16  0:17 Manoj Iyer
2005-02-16  1:09 ` Daniel Jacobowitz [this message]
2005-02-16  2:18   ` Joel Brobecker
2005-02-16  3:24     ` Daniel Jacobowitz
2005-02-16 22:50       ` Joel Brobecker
2005-02-17 14:30         ` Daniel Jacobowitz
2005-02-17 17:43           ` Joel Brobecker
2005-02-17  0:38       ` Manoj Iyer
2005-02-17 14:06         ` Daniel Jacobowitz
2005-02-16 13:46   ` Manoj Iyer
2005-03-02 18:32   ` Manoj Iyer

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=20050215232018.GB8631@nevyn.them.org \
    --to=drow@false.org \
    --cc=ezannoni@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=manjo@austin.ibm.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