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
next prev parent 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