public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "jan dot kratochvil at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug symtab/11534] New: GDB ignores non-first symbol DIEs
Date: Fri, 23 Apr 2010 19:04:00 -0000	[thread overview]
Message-ID: <20100423190444.11534.jan.kratochvil@redhat.com> (raw)

echo 'namespace N { int v = 1; }' | g++ -nostdlib -o vv -g -x c++ -
objcopy -N _ZN1N1vE vv
gdb -nx -q -ex 'p N::v' -ex q ./vv
Address of symbol "N::v" is unknown.

Why?  There is DW_AT_location containing the address:

 <1><29>: Abbrev Number: 2 (DW_TAG_namespace)
    <2a>   DW_AT_name        : N
 <2><32>: Abbrev Number: 3 (DW_TAG_variable)
    <33>   DW_AT_name        : v
    <37>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x5a): _ZN1N1vE
    <3f>   DW_AT_external    : 1
    <40>   DW_AT_declaration : 1
 <1><49>: Abbrev Number: 5 (DW_TAG_variable)
    <4a>   DW_AT_specification: <0x32>
    <4e>   DW_AT_location    : 9 byte block: 3 e8 0 60 0 0 0 0 0       
(DW_OP_addr: 6000e8)

Question: Is it valid to specifify both DW_AT_external and DW_AT_location
without any ELF symbol for it?  It seems to be DWARF standard compliant.

Currently GDB takes only the first DIE definition of symbol.  It is because
finish_block is careful to create symbol table in the read-in order and later
lookup functions only find the first symbol present.

Therefore DIE 0x49 gets ignored.  Therefore GDB creates LOC_UNRESOLVED symbol
and later resolves it via the ELF symbol table.

According to DWARF4 "2.13.2 Declarations Completing Non-Defining Declarations"
keyword "earlier" GDB should use only the last DIE specifying a symbol to
intepret the most complete symbol DIE.

We must not change dict_create_linear order as it would change at least the
function parameters order (a, b) to (b, a).

Changing the dict_create_hashed order seems to do the right thing.
Just that moment we break copy-relocations, tested by new attached
        gdb.base/shlib-copy-reloc.exp

We should not interpret DW_AT_location for DIEs with DW_AT_external as in such
case we should prefer the ELF symbol - possibly the copy relocation from
different objfile.  More details on this subject by Roland McGrath:
        Re: Cross-CU C++ DIE references vs. mangling
        http://sourceware.org/ml/archer/2010-q1/msg00092.html
DWARF standard does not seem to indicate anything about ignoring DW_AT_location
when DW_AT_external is present;  DW_AT_location probably should not be present.

Attached patch starts ignoring DW_AT_location for for DIEs with DW_AT_external.

GCC seems to workaround GDB by providing the two DIEs (0x32 and 0x49) using
DW_AT_specification.  It could simply provide a single merged DIE instead.
There is a problem with gfortran as it does not provide this GDB workaround.

There is GCC PR debug/40040.  Roland's GCC PR debug/40040 Comment 4 suggests
how to drop any ELF dependencies (requiring a mangling logic) by providing
self-contained GOT-referencing DWARF expressions.

-- 
           Summary: GDB ignores non-first symbol DIEs
           Product: gdb
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: symtab
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: jan dot kratochvil at redhat dot com
                CC: gdb-prs at sourceware dot org
GCC target triplet: x86_64-unknown-linux-gnu


http://sourceware.org/bugzilla/show_bug.cgi?id=11534

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


             reply	other threads:[~2010-04-23 19:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-23 19:04 jan dot kratochvil at redhat dot com [this message]
2010-04-23 19:05 ` [Bug symtab/11534] " jan dot kratochvil at redhat dot com

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=20100423190444.11534.jan.kratochvil@redhat.com \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /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).