public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Omar Sandoval <osandov@osandov.com>
To: Mark Wielaard <mark@klomp.org>
Cc: elfutils-devel@sourceware.org
Subject: Re: [PATCH 07/14] libdw: Recognize .debug_[ct]u_index sections in dwarf_elf_begin
Date: Wed, 1 Nov 2023 10:30:19 -0700	[thread overview]
Message-ID: <ZUKLK2GswvcemleV@telecaster> (raw)
In-Reply-To: <051e05da49fc84a0100f1865f0fca1d501cbeb49.camel@klomp.org>

On Wed, Nov 01, 2023 at 03:03:57PM +0100, Mark Wielaard wrote:
> Hi Omar,
> 
> On Wed, 2023-09-27 at 11:20 -0700, Omar Sandoval wrote:
> > From: Omar Sandoval <osandov@fb.com>
> > 
> > DWARF package (.dwp) files have a .debug_cu_index section and,
> > optionally, a .debug_tu_index section.  Add them to the list of DWARF
> > sections.
> > 
> > Unfortunately, it's not that simple: the other debug sections in a dwp
> > file have names ending with .dwo, which confuses the checks introduced
> > by commit 5b21e70216b8 ("libdw: dwarf_elf_begin should use either plain,
> > dwo or lto DWARF sections.").  So, we also have to special case
> > .debug_cu_index and .debug_tu_index in scn_dwarf_type and check_section
> > to treat them as TYPE_DWO sections.
> 
> This seems to work, but I wonder if we should have a specific TYPE_DWP?

I tried this, and it made check_section even more confusing (because
then we need a more complicated check than result->type == section
type). I came to the same conclusion that since this is internal for
now, it didn't really matter. Although maybe the name TYPE_SPLIT would
make more sense now rather than overloading TYPE_DWO.

When this becomes public, separate TYPE_DWO and TYPE_DWP types might be
nicer so that a hypothetical dwarf_get_type function could tell you
whether you got a dwo file or a dwp file.

> It doesn't really matter now, because the enum dwarf_type is only used
> internally. But I was hoping to extend the dwarf_begin interface with a
> flag so that you can open a DWARF as a specific type. For example there
> are single file split DWARF files. Which contain both "plain" and
> ".dwo" sections. Currently you can only open them as "plain", but there
> are actually two "views" of such files.
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=28573
> 
> Do you think there are reasons to open a file as either TYPE_DWO or
> TYPE_DWP? Or doesn't that not make sense?

If we were to treat a dwp file as a dwo file, I guess we'd have to
pretend it only contained one unit and ignore the rest, which I don't
think makes much sense. So even if we had separate types for them, I
don't know if we should allow that.

  reply	other threads:[~2023-11-01 17:30 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
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 [this message]
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=ZUKLK2GswvcemleV@telecaster \
    --to=osandov@osandov.com \
    --cc=elfutils-devel@sourceware.org \
    --cc=mark@klomp.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).