public inbox for
 help / color / mirror / Atom feed
From: Aaron Merey <>
To: Mark Wielaard <>
Cc: "Frank Ch. Eigler" <>,
Subject: Re: [PATCH] debuginfod: Support queries for ELF/DWARF sections
Date: Wed, 26 Oct 2022 13:57:02 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Mark,

On Wed, Oct 26, 2022 at 11:06 AM Mark Wielaard <> wrote:
> On Mon, 2022-10-24 at 14:38 -0400, Frank Ch. Eigler via Elfutils-devel
> wrote:
> > - not sure I understand why the code worries about dots in or not in
> >   section names.  Why not just pass them verbatim throughout the code
> >   base, and not worry about whether or not there's a dot?  Does the
> >   ELF standard even require a dot?
> I agree that just passing them through as is might be better. The ELF
> standard doesn't say much about section names, just:
>    Section names with a dot (.) prefix are reserved for the system,
>    although applications may use these sections if their existing
>    meanings are satisfactory. Applications may use names without the
>    prefix to avoid conflicts with system sections.

Agreed, will fix.

> I would drop the maybe_debuginfo_section heuristics. There are some
> sections like .strtab/.symtab that are probably in the debug file, but
> might be in the executable. I would assume that a named section can
> normally be found in the debugfile and only use the executable as
> fallback.
> So see if you can find the .debug file, if you can, then look for the
> section by name. If it isn't SHT_NOBITS you found it. If it is
> SHT_NOBITS the section should be in the exe. If the section cannot be
> found by name (in the .debug file) you can stop searching, it also
> won't be in the exe. If you cannot find the .debug file, or the section
> was in the .debug file, but had type SHT_NOBITS then search for the exe
> file and the named section in there.

I like this heuristic.  It's simpler and we don't have to update anything
if/when a new section becomes common.

> Finally, if the section comes from a file in the cache or if we have to
> download it in full anyway, then extracting the section into its own
> file seems slightly wasteful. It would be great if we could just report
> back "here is the full exe/debug file which does contain the requested
> section name". But that might make the interface a little ugly.
> int
> debuginfod_find_section (debuginfod_client *client,
>                          const unsigned char *build_id,
>                          int build_id_len,
>                          const char *section, char **path,
>                          bool *file_is_elf)
> Maybe that is over-designed to avoid a little bit of disk waste?

We'd save a bit of disk space but complicate the API and often
cause client tools to have to do more work to get at the section
contents.  In the case of .gdb_index, gdb already knows how to read
the index from a separate file.  Of course it can read the section
from an ELF file too but I suspect there might need to be some
changes to teach it how to handle "unusual" ELF files that only
contain a single section.

> Since debuginfod-client.c already includes system.h it can use:
> static inline ssize_t
> write_retry (int fd, const void *buf, size_t len)
> Which takes care of partial and/or interrupted write calls.

Thanks that's exactly what I'm looking for.


  parent reply	other threads:[~2022-10-26 17:57 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-21  0:06 [PATCH v2] " Aaron Merey
2022-10-22  0:09 ` [PATCH] " Aaron Merey
2022-10-24 18:38   ` Frank Ch. Eigler
2022-10-26 14:57     ` Mark Wielaard
2022-10-26 15:28       ` Frank Ch. Eigler
2022-10-26 17:57       ` Aaron Merey [this message]
2022-10-26 15:25     ` Mark Wielaard
2022-10-26 17:55     ` Aaron Merey
  -- strict thread matches above, loose matches on Subject: below --
2022-09-28  2:10 Aaron Merey
2022-09-28 14:28 ` Frank Ch. Eigler
2022-09-28 18:20   ` Aaron Merey

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:

* 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).