Re: Does gdb debuginfod download libc etc.?

On Wed, 2026-03-11 at 09:28 +0000, Andrew Burgess wrote:
> 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.

Hi Andrew; working more with this patch I think there might be an issue
with it: when I use it with my cores that don't have NT_FILE it works
well.  But, when I use it with a core file that DOES have NT_FILE, it
has some odd behavior: basically some of the filenames found during the
map have invalid names (names with control characters etc.)

Note, this is from GDB 17.1 with your patch applied, working with a
normal core file generated by the Linux kernel (via kill -6); I can see
from readelf -n that the NT_FILE section looks normal with no funky
characters in the filenames.

GDB shows:

[core-load] build_file_mappings: enter
  [core-load] operator(): start = 0x0, end = 0x67dc, filename = NONE, build-id = NONE
  [core-load] operator(): start = 0x200000, end = 0x521000, filename = , build-id = 38abc1e51499f5610bdd123e6336f7cb0f4146c2
  [core-load] operator(): start = 0x521000, end = 0x728000, filename = , build-id = NONE
  [core-load] operator(): start = 0x728000, end = 0x735000, filename = ^F, build-id = NONE

(here the ^F in the filename is the actual ASCII char 15).  Then some
OK stuff then more problematic filenames:

  [core-load] operator(): start = 0x737000, end = 0x947000, filename = NONE, build-id = NONE
  [core-load] operator(): start = 0x7fa8d9a00000, end = 0x7fa8e0400000, filename = NONE, build-id = NONE
  [core-load] operator(): start = 0x7fa8e1600000, end = 0x7fa8e8c00000, filename = NONE, build-id = NONE
...
  [core-load] operator(): start = 0x7fa93a398000, end = 0x7fa93a3c0000, filename = <D6>^A, build-id = 095c7ba148aeca81668091f718047078d57efddb
  [core-load] operator(): start = 0x7fa93a3c0000, end = 0x7fa93a555000, filename = , build-id = NONE
  [core-load] operator(): start = 0x7fa93a555000, end = 0x7fa93a5ad000, filename = , build-id = NONE
  [core-load] operator(): start = 0x7fa93a5ad000, end = 0x7fa93a5ae000, filename = e, build-id = NONE
  [core-load] operator(): start = 0x7fa93a5ae000, end = 0x7fa93a5b2000, filename = P^A, build-id = NONE
  [core-load] operator(): start = 0x7fa93a5b2000, end = 0x7fa93a5b4000, filename = , build-id = NONE
  [core-load] operator(): start = 0x7fa93a5b4000, end = 0x7fa93a5c3000, filename = NONE, build-id = NONE
  [core-load] operator(): start = 0x7fa93a5c3000, end = 0x7fa93a5c4000, filename = E^A, build-id = 34f1f6beeaed8ab30ee4056ff1cc053f8d05c153
  [core-load] operator(): start = 0x7fa93a5c4000, end = 0x7fa93a5c5000, filename = , build-id = NONE
  [core-load] operator(): start = 0x7fa93a5c5000, end = 0x7fa93a5c6000, filename = X, build-id = NONE
...
  [core-load] operator(): start = 0x7fa93a5cb000, end = 0x7fa93a5e2000, filename = , build-id = NONE
  [core-load] operator(): start = 0x7fa93a5e2000, end = 0x7fa93a5e6000, filename = , build-id = NONE
  [core-load] operator(): start = 0x7fa93a5e6000, end = 0x7fa93a5e7000, filename = ^?^K, build-id = NONE
  [core-load] operator(): start = 0x7fa93a5e7000, end = 0x7fa93a5e8000, filename = <80>^K, build-id = NONE
  [core-load] operator(): start = 0x7fa93a5e8000, end = 0x7fa93a5f6000, filename = /usr/l <A4>^?^K, build-id = 2ac471af4796e5b69e0e2dde85c3d3dacdcc0b3d
  [core-load] operator(): start = 0x7fa93a5f6000, end = 0x7fa93a672000, filename = , build-id = NONE
  [core-load] operator(): start = 0x7fa93a672000, end = 0x7fa93a6cd000, filename = /usr/l<E0><A3>^?^K, build-id = NONE
  [core-load] operator(): start = 0x7fa93a6cd000, end = 0x7fa93a6ce000, filename = , build-id = NONE
  [core-load] operator(): start = 0x7fa93a6ce000, end = 0x7fa93a6cf000, filename = /usr/l@<A4>^?^K, build-id = NONE

I think something here might have messed up the parsing of the filename
section of the NT_FILE section?  I'll try to look into this and see if
I can find it.