From: "jistone at redhat dot com" <email@example.com>
Subject: [Bug tools/22288] eu-addr2line doesn't find a rust file:line
Date: Thu, 12 Oct 2017 20:49:00 -0000 [thread overview]
Message-ID: <bug-22288-10460-ZAeB3LHnWM@http.sourceware.org/bugzilla/> (raw)
--- Comment #2 from Josh Stone <jistone at redhat dot com> ---
(In reply to Mark Wielaard from comment #1)
> But if there are .debug_aranges then it seems bad to assume they
> are wrong or incomplete.
I think it's safe to trust that given aranges are valid, but not that they're
complete. The binary may be composed of objects from multiple compilers, with
different policies toward aranges, and the final user linking it all may not be
able to control this.
> Best would be to fix rustc to generate .debug_aranges.
I found that Clang also doesn't emit .debug_aranges by default, but it has
-gdwarf-aranges for that. This passes to LLVM -generate-arange-section, and in
fact "rustc -Cllvm-args=-generate-arange-section" does work!
I can talk to upstream about making that the default, but they may well take a
similar stance as Clang, that it's redundant with other pc/range info.
> Second best would be to have a mechanism to for scanning all CUs and
> (re)create the same cache that dwarf_getaranges() would create from the
> .debug_aranges section for the CU. One question is if this isn't the default
> how it interacts with other users of the aranges cache like dwarf_addrdie,
> dwfl_module_addrdie and dwfl_module_getsrc. The last one is what
> eu-addr2line (and eu-stack) use.
I think this mechanism is desirable even if rustc changes its default. Start
with the aranges, and lazily augment it with a CU scan if that misses. But I
don't doubt there are tricky corners to this.
You are receiving this mail because:
You are on the CC list for the bug.
next prev parent reply other threads:[~2017-10-12 20:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-12 18:56 [Bug tools/22288] New: " jistone at redhat dot com
2017-10-12 20:36 ` [Bug tools/22288] " mark at klomp dot org
2017-10-12 20:49 ` jistone at redhat dot com [this message]
2017-10-12 22:42 ` jistone at redhat dot com
2019-11-19 17:24 ` jistone at redhat dot com
2022-05-24 0:18 ` dblaikie at gmail dot com
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).