Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: psmith@gnu.org
Cc: Andrew Burgess <aburgess@redhat.com>, gdb@sourceware.org
Subject: Re: Does gdb debuginfod download libc etc.?
Date: Tue, 10 Mar 2026 10:12:03 +0100	[thread overview]
Message-ID: <20260310091203.GB5634@gnu.wildebeest.org> (raw)
In-Reply-To: <ec483a582f9055456dd0591208eb148a28007381.camel@gnu.org>

Hi Paul,

On Mon, Mar 09, 2026 at 05:19:44PM -0400, Paul Smith via Gdb wrote:
> (Most of) my core files are generated by the Google coredumper library,
> not by the Linux kernel, and I guess they don't have this note section.
> 
> It appears that this note section isn't actually required in order for
> us to access the build ID values (after all, elfutils does it), but
> this function gives up if the section doesn't exist.
> 
> I can look into how to force my cores to have this section, but I'd
> really like to teach GDB how to handle core files without it, since I
> have a lot of them and will likely continue to get them for some time
> even if I do manage to make this change to new releases.

Not sure this helps, since I know very little about gdb/bfd, but the
way elfutils gets at the build-id is to represent each core PT_LOAD as
an Elf and then tries to read the NOTEs either through the section
headers or the program headers. See
https://sourceware.org/cgit/elfutils/tree/libdwelf/dwelf_elf_gnu_build_id.c

This is somewhat simpler in elfutils because it just deals with ELF
files and doesn't care about other binary formats. Maybe there is a
simple mapping from bfd to elf sections/segements to do the same?

Cheers,

Mark

  reply	other threads:[~2026-03-10  9:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-07 23:58 Paul Smith via Gdb
2026-03-08  9:44 ` Arsen Arsenović via Gdb
2026-03-08 21:04   ` Paul Smith via Gdb
2026-03-09  2:32     ` Simon Marchi via Gdb
2026-03-09 13:57       ` Paul Smith via Gdb
2026-03-09 15:36         ` Simon Marchi via Gdb
2026-03-09 17:28           ` Andrew Burgess via Gdb
2026-03-09 16:57         ` Andrew Burgess via Gdb
2026-03-09 20:32           ` Paul Smith via Gdb
2026-03-09 21:19             ` Paul Smith via Gdb
2026-03-10  9:12               ` Mark Wielaard [this message]
2026-03-10 14:20               ` Andrew Burgess via Gdb
2026-03-10 17:12                 ` Paul Smith via Gdb
2026-03-11  9:28                   ` Andrew Burgess via Gdb
2026-03-11 14:46                     ` Paul Smith via Gdb
2026-03-12 20:38                     ` Paul Smith via Gdb
2026-03-13 13:45                       ` Andrew Burgess via Gdb
2026-03-13 15:44                         ` Paul Smith via Gdb

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=20260310091203.GB5634@gnu.wildebeest.org \
    --to=mark@klomp.org \
    --cc=aburgess@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=psmith@gnu.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