From: Mark Wielaard <mark@klomp.org>
To: Omar Sandoval <osandov@osandov.com>
Cc: elfutils-devel@sourceware.org
Subject: Re: [PATCH 05/14] libdw: Fix dwarf_macro_getsrcfiles for DWARF 5
Date: Tue, 3 Oct 2023 23:29:57 +0200 [thread overview]
Message-ID: <20231003212957.GG32765@gnu.wildebeest.org> (raw)
In-Reply-To: <bdd28a8a6fa01c0472119b8fdea2dce055f8544a.1695837512.git.osandov@fb.com>
Hi Omar,
On Wed, Sep 27, 2023 at 11:20:54AM -0700, Omar Sandoval wrote:
> Dwarf_Macro_Op_Table::is_64bit conflates the address size and the offset
> size: for .debug_macinfo, it is initialized based on the compilation
> unit's address size, but for .debug_macro, it is initialized based on
> the macro unit's offset size. is_64bit is used to determine the address
> size to pass to __libdw_getsrclines. For a 64-bit architecture using
> DWARF 5 with 32-bit offsets (the common case), this fails because
> read_srclines checks that the given address size matches the address
> size from the line number program header.
>
> Fix it by splitting is_64bit into separate address_size and offset_size
> members.
Very nice catch. You are right that for DWARF5 the line table header
already gives the address_size. It is slightly embarassing our sanity
check here failed. Thanks for fixing.
I had to think a bit on why we didn't need to set the address_size for
the fake_cu. But that is only needed to read address class
forms. Which aren't valid forms in macro data.
Applied,
Mark
next prev parent reply other threads:[~2023-10-03 21:29 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-27 18:20 [PATCH 00/14] elfutils: DWARF package (.dwp) file support Omar Sandoval
2023-09-27 18:20 ` [PATCH 01/14] libdw: Make try_split_file static Omar Sandoval
2023-10-03 16:09 ` Mark Wielaard
2023-09-27 18:20 ` [PATCH 02/14] libdw: Handle split DWARF in dwarf_entrypc Omar Sandoval
2023-10-03 16:10 ` Mark Wielaard
2023-09-27 18:20 ` [PATCH 03/14] libdw: Handle DW_AT_ranges in split DWARF 5 skeleton in dwarf_ranges Omar Sandoval
2023-10-03 16:10 ` Mark Wielaard
2023-09-27 18:20 ` [PATCH 04/14] libdw: Handle other string forms in dwarf_macro_param2 Omar Sandoval
2023-10-03 16:11 ` Mark Wielaard
2023-09-27 18:20 ` [PATCH 05/14] libdw: Fix dwarf_macro_getsrcfiles for DWARF 5 Omar Sandoval
2023-10-03 21:29 ` Mark Wielaard [this message]
2023-09-27 18:20 ` [PATCH 06/14] libdw: Handle split DWARF in dwarf_macro_getsrcfiles Omar Sandoval
2023-10-03 21:49 ` Mark Wielaard
2023-09-27 18:20 ` [PATCH 07/14] libdw: Recognize .debug_[ct]u_index sections in dwarf_elf_begin Omar Sandoval
2023-11-01 14:03 ` Mark Wielaard
2023-11-01 17:30 ` Omar Sandoval
2023-09-27 18:20 ` [PATCH 08/14] libdw: Parse DWARF package file index sections Omar Sandoval
2023-11-01 23:07 ` Mark Wielaard
2023-11-07 6:45 ` Omar Sandoval
2023-09-27 18:20 ` [PATCH 09/14] libdw, libdwfl: Save original path of ELF file Omar Sandoval
2023-11-02 17:04 ` Mark Wielaard
2023-11-07 6:46 ` Omar Sandoval
2023-09-27 18:20 ` [PATCH 10/14] libdw: Try .dwp file in __libdw_find_split_unit() Omar Sandoval
2023-11-02 19:56 ` Mark Wielaard
2023-11-07 7:07 ` Omar Sandoval
2023-09-27 18:21 ` [PATCH 11/14] tests: Handle DW_MACRO_{define,undef}_{strx,sup} in dwarf-getmacros Omar Sandoval
2023-11-02 20:30 ` [PATCH 11/14] tests: Handle DW_MACRO_{define, undef}_{strx, sup} " Mark Wielaard
2023-09-27 18:21 ` [PATCH 12/14] tests: Optionally dump all units " Omar Sandoval
2023-11-02 20:39 ` Mark Wielaard
2023-09-27 18:21 ` [PATCH 13/14] libdw: Apply DWARF package file section offsets where appropriate Omar Sandoval
2023-11-02 22:20 ` Mark Wielaard
2023-11-07 16:55 ` Omar Sandoval
2023-09-27 18:21 ` [PATCH 14/14] libdw: Handle overflowed DW_SECT_INFO offsets in DWARF package file indexes Omar Sandoval
2023-09-27 19:20 ` [PATCH 00/14] elfutils: DWARF package (.dwp) file support Frank Ch. Eigler
2023-09-27 20:17 ` Omar Sandoval
2023-10-03 21:54 ` Mark Wielaard
2023-11-02 23:05 ` Mark Wielaard
2023-11-07 17:13 ` Omar Sandoval
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=20231003212957.GG32765@gnu.wildebeest.org \
--to=mark@klomp.org \
--cc=elfutils-devel@sourceware.org \
--cc=osandov@osandov.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).