public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: "wilson at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: elfutils-devel@sourceware.org
Subject: [Bug libdw/27805] libdwfl: Unable to extract source line information for RISC-V binary
Date: Sat, 01 May 2021 20:48:57 +0000	[thread overview]
Message-ID: <bug-27805-10460-fE4Ts29XOK@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-27805-10460@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=27805

Jim Wilson <wilson at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu.org

--- Comment #1 from Jim Wilson <wilson at gcc dot gnu.org> ---
Using readelf -wr to look at the debug_aranges section, I see entries like

  Length:                   44
  Version:                  2
  Offset into .debug_info:  0x987
  Pointer Size:             4
  Segment Size:             0

    Address    Length
    00000000 00000000
    20400132 00000002
    20400134 0000003a
    00000000 00000000

An address/length entry of 0/0 is supposed to mark the end of the list, but
here we have one at the beginning.  This is confusing elfutils which is trying
to move byte by byte through the aranges section. libdw/dwarf_aranges.c has
          /* Two zero values mark the end.  */
          if (range_address == 0 && range_length == 0)
            break;
and then assumes that the next entry is immediately following, which it isn't,
and it ends up reading garbage.  binutils seems to be using the length field to
find the last entry.  And readelf is ignoring the 0/0 end of list rule so that
we can see the invalid entries.

There are a lot of aranges that have 0/0 entries not at the end of the list.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

  reply	other threads:[~2021-05-01 20:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-30 12:31 [Bug libdw/27805] New: " n2knqf5ogu at bsogq dot anonbox.net
2021-05-01 20:48 ` wilson at gcc dot gnu.org [this message]
2021-05-05 14:36 ` [Bug libdw/27805] " mark at klomp dot org
2021-05-05 15:42 ` wilson at gcc dot gnu.org
2021-05-05 15:59 ` wilson at gcc dot gnu.org
2021-05-06  9:43 ` mark at klomp dot org
2021-07-28 11:55 ` n2knqf5ogu at bsogq dot anonbox.net
2023-10-06 12:10 ` mark at klomp dot org
2023-10-09 16:15 ` mark at klomp dot org

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=bug-27805-10460-fE4Ts29XOK@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=elfutils-devel@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).