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!