Re: Does gdb debuginfod download libc etc.?

Paul Smith via Gdb <[email protected]> Wed, 11 Mar 2026 10:46:39 -0400
Newsgroups gmane.comp.gdb.devel
Organization GNU's Not UNIX!
Message-ID <[email protected]>
On Wed, 2026-03-11 at 09:28 +0000, Andrew Burgess wrote:
> Glad this is unblocking you.  The operator() stuff is fine, it's just
> because the debug is being emitted from within a C++ lambda function.

Understood.  I just wasn't sure if you wanted to emit that as a debug
message.

> I started working on cleaning up the patch ready for submission to
> master, but I'm pretty busy for the next few days, so it'll probably
> be next week now before I post anything.

No worries at all.

> However, I'm not sure if this would ever be back-ported to the
> gdb-17-branch, this isn't a regression or bug fix, handling a missing
> NT_FILE note has never worked in GDB, so this is really a new
> functionality patch, which would normally only be applied to master.

I understand.  I've already incorporated it into my build environment
and I actually backported it to 16.3 which is what we're currently
using, so that I can deploy just a new GDB binary but keep all the same
other files (python etc.)  Later this year I'll switch to a newer GDB
and if 18 is not released at that point, I'll apply a patch to 17.x.

If I run into issues I can just disable it again (I'll let you know, if
it seems like a problem with the change versus something introduced by
my fiddling around).

In the meantime I'm looking into adding NT_FILE support to our cores. 
It doesn't look too difficult as I have all the necessary info,
although preserving the variable-length filenames will be interesting
as the coredumper library needs to run in a signal handler context, so
no malloc is available.  I see a few ways to handle this, I'll think
about it.

Thanks immensely Andrew!