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


On Mon, 2022-10-24 at 14:38 -0400, Frank Ch. Eigler via Elfutils-devel
> - 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.

Is/should the section name be URL-encoded?

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

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.

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.

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?



  reply	other threads:[~2022-10-26 14: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 [this message]
2022-10-26 15:28       ` Frank Ch. Eigler
2022-10-26 17:57       ` Aaron Merey
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).