* Does gdb debuginfod download libc etc.?
@ 2026-03-07 23:58 Paul Smith via Gdb
2026-03-08 9:44 ` Arsen Arsenović via Gdb
0 siblings, 1 reply; 18+ messages in thread
From: Paul Smith via Gdb @ 2026-03-07 23:58 UTC (permalink / raw)
To: gdb
I'm trying to start using debuginfod support in my environment. I've
started my own debuginfod server and I've added lots of historical
binaries and shared libraries that I get core files from.
In that past I've asked users to package up all their system libraries
such as libc.so, libm.so, libpthread.so, the runtime linker ld-linux.so
etc. and send them along with their core file. Then I run GDB like:
gdb -iex 'set sysroot xxx' -c core exe
What I was hoping to do is to run "gdb -c core" and have debuginfod get
everything I need without having to ask users to send anything
(assuming I've already got the libraries, which I usually do). But, it
doesn't seem to be working.
I've used debuginfod-find to verify that all the libraries referenced
by the core file do exist on the server (via their build ID).
When I run "gdb -c core" it DOES correctly download the executable
file, so I know that GDB's debuginfod configuration is working. It
also appears to download linux-vdso.so.1.
However, none of my other libraries are being loaded, even if I use bt
or whatever to look at the backtrace. Without libc for example, none
of the threads which were in the C runtime when the core was taken can
be traced and I just get "?? ()" for every frame. If I use "info
sharedlib" I see all the .so paths are the local system versions of
these libraries, and they have a "Syms Read" value of "No".
Is there something else I need to do to get this working?
Or am I just misunderstanding how debuginfod support works?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
2026-03-07 23:58 Does gdb debuginfod download libc etc.? Paul Smith via Gdb
@ 2026-03-08 9:44 ` Arsen Arsenović via Gdb
2026-03-08 21:04 ` Paul Smith via Gdb
0 siblings, 1 reply; 18+ messages in thread
From: Arsen Arsenović via Gdb @ 2026-03-08 9:44 UTC (permalink / raw)
To: Paul Smith; +Cc: gdb
[-- Attachment #1: Type: text/plain, Size: 8274 bytes --]
Hi Paul,
Paul Smith <psmith@gnu.org> writes:
> I'm trying to start using debuginfod support in my environment. I've
> started my own debuginfod server and I've added lots of historical
> binaries and shared libraries that I get core files from.
>
> In that past I've asked users to package up all their system libraries
> such as libc.so, libm.so, libpthread.so, the runtime linker ld-linux.so
> etc. and send them along with their core file. Then I run GDB like:
> gdb -iex 'set sysroot xxx' -c core exe
>
> What I was hoping to do is to run "gdb -c core" and have debuginfod get
> everything I need without having to ask users to send anything
> (assuming I've already got the libraries, which I usually do). But, it
> doesn't seem to be working.
>
> I've used debuginfod-find to verify that all the libraries referenced
> by the core file do exist on the server (via their build ID).
>
> When I run "gdb -c core" it DOES correctly download the executable
> file, so I know that GDB's debuginfod configuration is working. It
> also appears to download linux-vdso.so.1.
>
> However, none of my other libraries are being loaded, even if I use bt
> or whatever to look at the backtrace. Without libc for example, none
> of the threads which were in the C runtime when the core was taken can
> be traced and I just get "?? ()" for every frame. If I use "info
> sharedlib" I see all the .so paths are the local system versions of
> these libraries, and they have a "Syms Read" value of "No".
This is strange - I've tried replicating it.
For context, I run a debuginfod instance populated with packages I build
for my own Gentoo binhost. To test this, I got a dump from a few days
ago, and put it in a blank Arch Linux container (meaning it had access
to none of my installed libraries) with gdb 17.1, and told it to look up
debug info on my debuginfod server. It pulled all the libraries:
[root@bstg /]# gdb -c /host/core
GNU gdb (GDB) 17.1
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
This GDB supports auto-downloading debuginfo from the following URLs:
<http://localhost/debuginfod>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Downloading 559.69 K file /usr/bin/foot
Downloading 846.47 K file /usr/lib64/libpcre2-8.so.0.15.0
Downloading 182.12 K file /usr/lib64/libgraphite2.so.3.2.1
Downloading 1.43 M file /usr/lib64/libglib-2.0.so.0.8400.4
Downloading 302.20 K file /usr/lib64/libpng16.so.16.55.0
Downloading 97.14 K file /usr/lib64/libbz2.so.1.0.8
Downloading 122.19 K file /usr/lib64/libz.so.1.3.2
Downloading 1.40 M file /usr/lib64/libharfbuzz.so.0.61232.0
Downloading 210.12 K file /usr/lib64/libexpat.so.1.11.2
Downloading 1.13 M file /usr/lib64/libfreetype.so.6.20.4
Downloading 66.27 K file /usr/lib64/libffi.so.8.2.0
Downloading 2.29 M file /usr/lib64/libc.so.6
Downloading 146.17 K file /usr/lib64/libfcft.so.4.3.2
Downloading 350.05 K file /usr/lib64/libutf8proc.so.3.2.3
Downloading 398.13 K file /usr/lib64/libfontconfig.so.1.16.0
Downloading 438.34 K file /usr/lib64/libxkbcommon.so.0.13.1
Downloading 38.64 K file /usr/lib64/libwayland-cursor.so.0.24.0
Downloading 62.91 K file /usr/lib64/libwayland-client.so.0.24.0
Downloading 1.17 M file /usr/lib64/libpixman-1.so.0.46.4
Downloading 1.15 M file /usr/lib64/libm.so.6
Downloading 3.19 M file /usr/lib64/ld-linux-x86-64.so.2
[New LWP 44937]
[New LWP 44936]
[New LWP 44927]
[New LWP 44935]
[New LWP 44933]
[New LWP 44940]
[New LWP 44938]
[New LWP 44939]
[New LWP 44934]
[New LWP 44930]
[New LWP 44932]
[New LWP 44931]
[New LWP 44929]
[New LWP 44928]
[New LWP 44925]
[New LWP 44926]
[New LWP 44900]
Reading symbols from /root/.cache/debuginfod_client/abbc57ebe52352cc4ffa93ac153b7c0fe2a58249/executable...
Downloading 1.15 M separate debug info for /root/.cache/debuginfod_client/abbc57ebe52352cc4ffa93ac153b7c0fe2a58249/executable
Reading symbols from /root/.cache/debuginfod_client/abbc57ebe52352cc4ffa93ac153b7c0fe2a58249/debuginfo...
Downloading 2.28 M separate debug info for /root/.cache/debuginfod_client/38175f895390f3e40aa5bb2706b7647f2bac973d/executable
Downloading 2.26 M separate debug info for /root/.cache/debuginfod_client/7c3be6dccd26bb757832f7771fad5fb212389ffb/executable
Downloading 143.06 K separate debug info for /root/.cache/debuginfod_client/38601e6dd2b36f0ca50de7f91428cb04c3f5daf0/executable
Downloading 75.24 K separate debug info for /root/.cache/debuginfod_client/e25df18e5a3dc25042cf8416296e719060108659/executable
Downloading 587.47 K separate debug info for /root/.cache/debuginfod_client/70848bd835b74ec3fb95052083ddc6f1373f39d8/executable
Downloading 711.10 K separate debug info for /root/.cache/debuginfod_client/e90348e8ad4f35454f86a262ec0b0ccab6b8b801/executable
Downloading 34.14 K separate debug info for /root/.cache/debuginfod_client/887865c3d0a8c001dd6b69951e2580ab1828e0ad/executable
Downloading 244.07 K separate debug info for /root/.cache/debuginfod_client/70cb794006d13437bb56195bd7994b1bf71ab23c/executable
Downloading 6.05 M separate debug info for /root/.cache/debuginfod_client/22ca58d9cfb2479c0f72b964e33727b4ee98425d/executable
Downloading 118.19 K separate debug info for /root/.cache/debuginfod_client/cc25dd3b84efdaab8afc4773179518016873eb53/executable
Downloading 1.78 M separate debug info for /root/.cache/debuginfod_client/6691a92dfa6857e5f9447ae05c02cfc3f567560f/executable
Downloading 272.71 K separate debug info for /root/.cache/debuginfod_client/ecbc8c047da9ad5284444c510628c7124e03f0fe/executable
Downloading 13.00 M separate debug info for /root/.cache/debuginfod_client/6caf7bc7ac5a7afaa9270090608a5d695600bd20/executable
Downloading 176.43 K separate debug info for /root/.cache/debuginfod_client/e3c6680e6a61d29aa8b4b3e84d7001468d1cb39a/executable
Downloading 101.69 K separate debug info for /root/.cache/debuginfod_client/c62bf82cb11187867183bf2644ee2042e08c4d08/executable
Downloading 525.26 K separate debug info for /root/.cache/debuginfod_client/c86efb7898aec6ad91a7a537375bf0edeaea0d05/executable
Downloading 2.38 M separate debug info for /root/.cache/debuginfod_client/41b432ccf719b8a5a62b00472107d8d2798cf02a/executable
Downloading 629.27 K separate debug info for /root/.cache/debuginfod_client/ed7f3f1ce1d5d639459b5f61a063d550d9b5571e/executable
Downloading 1.07 M separate debug info for /root/.cache/debuginfod_client/b6705f4c7b443400e9f3136658df3ea38e7551c0/executable
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/bin/foot'.
Program terminated with signal SIGSEGV, Segmentation fault.
Downloading 181.82 K source file /usr/src/debug/gui-apps/foot-1.25.0/foot-1.25.0-build/../foot-1.25.0/render.c
#0 0x0000564ed601552c in render_worker_thread (_ctx=<optimized out>) at ../foot-1.25.0/render.c:2259
2259 pixman_image_composite32(PIXMAN_OP_SRC,
[Current thread is 1 (Thread 0x7f87bd7fa6c0 (LWP 44937))]
Do the binaries and libraries the program that dumped core have build
IDs? More information is probably needed to be able to tell what
happened.
You can probably try debugging this by setting:
set debug separate-debug-file on
... or such, to see whether gdb knows about the build IDs.
--
Arsen Arsenović
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
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
0 siblings, 1 reply; 18+ messages in thread
From: Paul Smith via Gdb @ 2026-03-08 21:04 UTC (permalink / raw)
To: Arsen Arsenović; +Cc: gdb
On Sun, 2026-03-08 at 10:44 +0100, Arsen Arsenović wrote:
> This is strange - I've tried replicating it.
Thanks for making that effort!
> For context, I run a debuginfod instance populated with packages I
> build for my own Gentoo binhost. To test this, I got a dump from a
> few days ago, and put it in a blank Arch Linux container (meaning it
> had access to none of my installed libraries) with gdb 17.1, and told
> it to look up debug info on my debuginfod server. It pulled all the
> libraries
That definitely looks like what I had hoped to see. However it doesn't
work for me. FWIW I forgot to mention I'm using GDB 17.1 that I built
myself using latest elfutils with all the stuff in it that is needed
(json-c, curl, xz/zstd, etc.) (I hope!!)
I'm confident that all the binaries etc. have build IDs: if I run
"eu-unstrip -n --core core" then not only do I see all the build IDs,
but eu-unstrip actually downloads everything correctly from the
debuginfod server! Before I run it my cache is empty, afterwards it
has all the things in it.
But, they are still not loaded by GDB (I guess that makes sense--if it
were trying to load them and failing I'd see messages).
> You can probably try debugging this by setting:
>
> set debug separate-debug-file on
>
> ... or such, to see whether gdb knows about the build IDs.
I tried enabling this but didn't learn much. I don't use any separate
debug info: all my libraries have the debuginfo in the file itself. I
did discover that setting DEBUGINFOD_VERBOSE before starting GDB will
show internal debug info from the debuginfod library so I ran this:
DEBUGINFOD_VERBOSE=9 gdb -c core
Here's the output I get:
---------------
[separate-debug-file] build_id_to_bfd_suffix: enter
[separate-debug-file] build_id_to_debug_bfd_1: Trying
/lib/debug/.build-id/f8/7c1d8cd2118209ef2350b22b187a64d705d6cd...
[separate-debug-file] build_id_to_debug_bfd_1: path doesn't exist
[separate-debug-file] build_id_to_debug_bfd_1: no suitable file found
[separate-debug-file] build_id_to_bfd_suffix: exit
debuginfod_find_executable f87c1d8cd2118209ef2350b22b187a64d705d6cd
server urls "http://debuginfod:8002"
checking build-id
checking cache dir /home/pds/.cache/debuginfod_client
found
/home/pds/.cache/debuginfod_client/f87c1d8cd2118209ef2350b22b187a64d705
d6cd/hdr-executable (bytes=55)
found
/home/pds/.cache/debuginfod_client/f87c1d8cd2118209ef2350b22b187a64d705
d6cd/executable (fd=14)
Reading symbols from
/home/pds/.cache/debuginfod_client/f87c1d8cd2118209ef2350b22b187a64d705
d6cd/executable...
⚠️ warning: platform-specific solib_create_inferior_hook did not load
initial shared libraries.
⚠️ warning: .dynamic section for "/lib64/ld-linux-x86-64.so.2" is not
at the expected address (wrong library or version mismatch?)
⚠️ warning: Could not load shared library symbols for 9 libraries, e.g.
/opt/lib64/libicui18n.so.75.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
Reading symbols from /lib64/ld-linux-x86-64.so.2...
[separate-debug-file] find_separate_debug_file_by_buildid: start:
looking for separate debug info (build-id) for /lib64/ld-linux-x86-
64.so.2
[separate-debug-file] build_id_to_bfd_suffix: enter
[separate-debug-file] build_id_to_debug_bfd_1: Trying
/lib/debug/.build-id/8c/fa19934886748ff4603da8aa8fdb0c2402b8cf.debug...
[separate-debug-file] build_id_to_debug_bfd_1: path doesn't exist
[separate-debug-file] build_id_to_debug_bfd_1: no suitable file
found
[separate-debug-file] build_id_to_bfd_suffix: exit
[separate-debug-file] find_separate_debug_file_by_buildid: end: looking
for separate debug info (build-id) for /lib64/ld-linux-x86-64.so.2
debuginfod_find_debuginfo 8cfa19934886748ff4603da8aa8fdb0c2402b8cf
server urls "http://debuginfod:8002"
checking build-id
checking cache dir /home/pds/.cache/debuginfod_client
not found No such file or directory (err=-2)
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
Reading symbols from system-supplied DSO at 0x7ffff85e4000...
[separate-debug-file] find_separate_debug_file_by_buildid: start:
looking for separate debug info (build-id) for system-supplied DSO at
0x7ffff85e4000
[separate-debug-file] build_id_to_bfd_suffix: enter
[separate-debug-file] build_id_to_debug_bfd_1: Trying
/lib/debug/.build-id/bf/619d454c75501884ae152c241f1f2c2039f532.debug...
[separate-debug-file] build_id_to_debug_bfd_1: path doesn't exist
[separate-debug-file] build_id_to_debug_bfd_1: no suitable file
found
[separate-debug-file] build_id_to_bfd_suffix: exit
[separate-debug-file] find_separate_debug_file_by_buildid: end: looking
for separate debug info (build-id) for system-supplied DSO at
0x7ffff85e4000
debuginfod_find_debuginfo bf619d454c75501884ae152c241f1f2c2039f532
server urls "http://debuginfod:8002"
checking build-id
checking cache dir /home/pds/.cache/debuginfod_client
not found No such file or directory (err=-2)
(No debugging symbols found in system-supplied DSO at 0x7ffff85e4000)
Core was generated by `/opt/bin/exe'.
#0 0x0000000001fa11ca in WriteCompressedCoreDump ()
[Current thread is 1 (LWP 2184998)]
---------------
I wonder if it has something to do with this:
> ⚠️ warning: platform-specific solib_create_inferior_hook did not load
> initial shared libraries.
But I don't know what that means or how to go further in debugging.
Based on the lack of debuginfod verbose output, GDB is not even asking
to load those libraries so it seems to be something more basic / in GDB
itself, not in the debuginfod support.
Maybe there's some autoconf switch or library that I'm missing?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
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
0 siblings, 1 reply; 18+ messages in thread
From: Simon Marchi via Gdb @ 2026-03-09 2:32 UTC (permalink / raw)
To: psmith, Arsen Arsenović; +Cc: gdb
On 2026-03-08 17:04, Paul Smith via Gdb wrote:
> [separate-debug-file] build_id_to_bfd_suffix: enter
> [separate-debug-file] build_id_to_debug_bfd_1: Trying
> /lib/debug/.build-id/f8/7c1d8cd2118209ef2350b22b187a64d705d6cd...
> [separate-debug-file] build_id_to_debug_bfd_1: path doesn't exist
> [separate-debug-file] build_id_to_debug_bfd_1: no suitable file found
> [separate-debug-file] build_id_to_bfd_suffix: exit
> debuginfod_find_executable f87c1d8cd2118209ef2350b22b187a64d705d6cd
> server urls "http://debuginfod:8002"
> checking build-id
> checking cache dir /home/pds/.cache/debuginfod_client
> found
> /home/pds/.cache/debuginfod_client/f87c1d8cd2118209ef2350b22b187a64d705
> d6cd/hdr-executable (bytes=55)
> found
> /home/pds/.cache/debuginfod_client/f87c1d8cd2118209ef2350b22b187a64d705
> d6cd/executable (fd=14)
> Reading symbols from
> /home/pds/.cache/debuginfod_client/f87c1d8cd2118209ef2350b22b187a64d705
> d6cd/executable...
>
> ⚠️ warning: platform-specific solib_create_inferior_hook did not load
> initial shared libraries.
>
> ⚠️ warning: .dynamic section for "/lib64/ld-linux-x86-64.so.2" is not
> at the expected address (wrong library or version mismatch?)
>
> ⚠️ warning: Could not load shared library symbols for 9 libraries, e.g.
> /opt/lib64/libicui18n.so.75.
> Use the "info sharedlibrary" command to see the complete listing.
> Do you need "set solib-search-path" or "set sysroot"?
> Reading symbols from /lib64/ld-linux-x86-64.so.2...
> [separate-debug-file] find_separate_debug_file_by_buildid: start:
> looking for separate debug info (build-id) for /lib64/ld-linux-x86-
> 64.so.2
> [separate-debug-file] build_id_to_bfd_suffix: enter
> [separate-debug-file] build_id_to_debug_bfd_1: Trying
> /lib/debug/.build-id/8c/fa19934886748ff4603da8aa8fdb0c2402b8cf.debug...
> [separate-debug-file] build_id_to_debug_bfd_1: path doesn't exist
> [separate-debug-file] build_id_to_debug_bfd_1: no suitable file
> found
> [separate-debug-file] build_id_to_bfd_suffix: exit
> [separate-debug-file] find_separate_debug_file_by_buildid: end: looking
> for separate debug info (build-id) for /lib64/ld-linux-x86-64.so.2
> debuginfod_find_debuginfo 8cfa19934886748ff4603da8aa8fdb0c2402b8cf
> server urls "http://debuginfod:8002"
> checking build-id
> checking cache dir /home/pds/.cache/debuginfod_client
> not found No such file or directory (err=-2)
> (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
I noticed a difference between the first debuginfod call (which
succeeds) and the second one (that fails). The first one is
debuginfod_find_executable and the second is debuginfod_find_debuginfo.
Could it be important?
Are you able to replicate those queries using the debuginfod-find CLI
tool?
This is equivalent to the first query, I would expect it to work:
debuginfod-find executable f87c1d8cd2118209ef2350b22b187a64d705d6cd
And this is equivalent to the second query, I would expect it to fail:
debuginfod-find debuginfo 8cfa19934886748ff4603da8aa8fdb0c2402b8cf
It would then be interesting to see if you are able to fetch the second
one using (assuming debuginfod really has it):
debuginfo-find executable 8cfa19934886748ff4603da8aa8fdb0c2402b8cf
Here is the documentation from the debuginfod man page for these two
requests:
/buildid/BUILDID/debuginfo
If the given buildid is known to the server, this request will
result in a binary object that contains the customary .*debug_*
sections. This may be a split debuginfo file as created by strip,
or it may be an original unstripped executable.
/buildid/BUILDID/executable
If the given buildid is known to the server, this request will
result in a binary object that contains the normal executable
segments. This may be a executable stripped by strip, or it may be
an original unstripped executable. ET_DYN shared li‐ braries are
considered to be a type of executable.
I'm thinking that your ld-linux library might not have debug info (the
.debug_* sections), so it might not be returned by the debuginfo
request, but it could be returned by the executable request. Even if it
does not have debug info, it would still be valuable for GDB to have it.
> I wonder if it has something to do with this:
>
>> ⚠️ warning: platform-specific solib_create_inferior_hook did not load
>> initial shared libraries.
GDB still ends up listing the shared libs, so it might be red herring.
It is still curious though. What OS are you on (I want to know which of
the solib-*.c implementations you are using)?
Simon
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
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 16:57 ` Andrew Burgess via Gdb
0 siblings, 2 replies; 18+ messages in thread
From: Paul Smith via Gdb @ 2026-03-09 13:57 UTC (permalink / raw)
To: Simon Marchi, Arsen Arsenović; +Cc: gdb
On Sun, 2026-03-08 at 22:32 -0400, Simon Marchi wrote:
> I noticed a difference between the first debuginfod call (which
> succeeds) and the second one (that fails). The first one is
> debuginfod_find_executable and the second is
> debuginfod_find_debuginfo. Could it be important?
I think this is not an issue.
> Are you able to replicate those queries using the debuginfod-find CLI
> tool? This is equivalent to the first query, I would expect it to
> work:
>
> debuginfod-find executable f87c1d8cd2118209ef2350b22b187a64d705d6cd
This is the build ID for my program, and this exists and is downloaded
properly.
> And this is equivalent to the second query, I would expect it to
> fail:
>
> debuginfod-find debuginfo 8cfa19934886748ff4603da8aa8fdb0c2402b8cf
This is the build ID for the debuginfo for my local system's runtime
linker /lib64/ld-linux-x86-64.so.2:
> [separate-debug-file] find_separate_debug_file_by_buildid: end:
> looking for separate debug info (build-id) for /lib64/ld-linux-x86-
> 64.so.2 debuginfod_find_debuginfo
> 8cfa19934886748ff4603da8aa8fdb0c2402b8cf
This doesn't exist in my debuginfod server. It might be nice to have
debuginfo for the runtime linker, but I've never had it for any of my
debugging sessions, because users very rarely install it on their
systems, and it's not been a problem.
Even if I wanted the debuginfo for the runtime linker, things have
already gone awry here because GDB is loading my LOCAL SYSTEM'S runtime
linker, when instead it should have downloaded the core file's runtime
linker which is a different file with a different build ID.
> > > ⚠️ warning: platform-specific solib_create_inferior_hook did not
> > > load initial shared libraries.
>
> GDB still ends up listing the shared libs, so it might be red
> herring. It is still curious though.
The reason I suggest this might be related is that it seems to me that
once we reach this point, GDB has already started to do the wrong
thing. For example as above, it's use the local system's ld-linux.so
rather than downloading the core file's ld-linux.so.
I would expect that I would see requests to the debuginfod server for
the shared libraries, including the runtime linker itself, but I don't
see any of that. It only tries to find the executable and the
debuginfo file for the local system's runtime linker, and it never
tries to find anything else.
It would be interesting if Arsen can repeat his (successful)
experiment, setting the DEBUGINFOD_VERBOSE=9 environment variable
first, so we can see where in the processing of GDB startup we should
expect to be seeing debuginfod requests.
> What OS are you on (I want to know which of the solib-*.c
> implementations you are using)?
I'm not sure what you mean by "OS" here; I'm on GNU/Linux x86-64 (as
can be seen from the name of my runtime linker :)). If you mean the
distribution, my local host is Ubuntu 22.04 LTS and the core file was
generated on, I believe, Red Hat EL 9.
I have built GDB from source, so I'm happy to add any debugging info or
run GDB itself inside GDB, if someone can point me to likely places to
look.
Thanks Simon!
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
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
1 sibling, 1 reply; 18+ messages in thread
From: Simon Marchi via Gdb @ 2026-03-09 15:36 UTC (permalink / raw)
To: psmith, Arsen Arsenović; +Cc: gdb
On 3/9/26 9:57 AM, Paul Smith wrote:
> On Sun, 2026-03-08 at 22:32 -0400, Simon Marchi wrote:
>> I noticed a difference between the first debuginfod call (which
>> succeeds) and the second one (that fails). The first one is
>> debuginfod_find_executable and the second is
>> debuginfod_find_debuginfo. Could it be important?
>
> I think this is not an issue.
>
>> Are you able to replicate those queries using the debuginfod-find CLI
>> tool? This is equivalent to the first query, I would expect it to
>> work:
>>
>> debuginfod-find executable f87c1d8cd2118209ef2350b22b187a64d705d6cd
>
> This is the build ID for my program, and this exists and is downloaded
> properly.
>
>> And this is equivalent to the second query, I would expect it to
>> fail:
>>
>> debuginfod-find debuginfo 8cfa19934886748ff4603da8aa8fdb0c2402b8cf
>
> This is the build ID for the debuginfo for my local system's runtime
> linker /lib64/ld-linux-x86-64.so.2:
Ah ok, I didn't catch that from your output, sorry.
>> [separate-debug-file] find_separate_debug_file_by_buildid: end:
>> looking for separate debug info (build-id) for /lib64/ld-linux-x86-
>> 64.so.2 debuginfod_find_debuginfo
>> 8cfa19934886748ff4603da8aa8fdb0c2402b8cf
>
> This doesn't exist in my debuginfod server. It might be nice to have
> debuginfo for the runtime linker, but I've never had it for any of my
> debugging sessions, because users very rarely install it on their
> systems, and it's not been a problem.
>
> Even if I wanted the debuginfo for the runtime linker, things have
> already gone awry here because GDB is loading my LOCAL SYSTEM'S runtime
> linker, when instead it should have downloaded the core file's runtime
> linker which is a different file with a different build ID.
>
>>>> ⚠️ warning: platform-specific solib_create_inferior_hook did not
>>>> load initial shared libraries.
>>
>> GDB still ends up listing the shared libs, so it might be red
>> herring. It is still curious though.
>
> The reason I suggest this might be related is that it seems to me that
> once we reach this point, GDB has already started to do the wrong
> thing. For example as above, it's use the local system's ld-linux.so
> rather than downloading the core file's ld-linux.so.
>
> I would expect that I would see requests to the debuginfod server for
> the shared libraries, including the runtime linker itself, but I don't
> see any of that. It only tries to find the executable and the
> debuginfo file for the local system's runtime linker, and it never
> tries to find anything else.
I would add a printf in core_target::build_file_mappings to print the
mapped files and their (if present) build-ids.
And then put a breakpoint or printf in solib_bfd_open, to see when GDB
tries to open the files for the solibs. It might be that we blindly
open the files from the host, and we could add some build-id checks to
avoid that (and ask debuginfod instead).
> It would be interesting if Arsen can repeat his (successful)
> experiment, setting the DEBUGINFOD_VERBOSE=9 environment variable
> first, so we can see where in the processing of GDB startup we should
> expect to be seeing debuginfod requests.
>
>> What OS are you on (I want to know which of the solib-*.c
>> implementations you are using)?
>
> I'm not sure what you mean by "OS" here; I'm on GNU/Linux x86-64 (as
> can be seen from the name of my runtime linker :)). If you mean the
> distribution, my local host is Ubuntu 22.04 LTS and the core file was
> generated on, I believe, Red Hat EL 9.
Yeah sorry, it was late.
> I have built GDB from source, so I'm happy to add any debugging info or
> run GDB itself inside GDB, if someone can point me to likely places to
> look.
It would be useful to add debug prints to corelow.c, where it reads the
mappings, and then in solib-svr4.c, where it tries to open the solibs.
I am of the opinion that if adding some debug prints helps you
troubleshoot a problem, then it is worth adding these debug prints
upstream, since they could help somebody else (or even you) in the
future.
Simon
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
2026-03-09 13:57 ` Paul Smith via Gdb
2026-03-09 15:36 ` Simon Marchi via Gdb
@ 2026-03-09 16:57 ` Andrew Burgess via Gdb
2026-03-09 20:32 ` Paul Smith via Gdb
1 sibling, 1 reply; 18+ messages in thread
From: Andrew Burgess via Gdb @ 2026-03-09 16:57 UTC (permalink / raw)
To: psmith, Simon Marchi, Arsen Arsenović; +Cc: gdb
Paul Smith via Gdb <gdb@sourceware.org> writes:
> On Sun, 2026-03-08 at 22:32 -0400, Simon Marchi wrote:
>> I noticed a difference between the first debuginfod call (which
>> succeeds) and the second one (that fails). The first one is
>> debuginfod_find_executable and the second is
>> debuginfod_find_debuginfo. Could it be important?
>
> I think this is not an issue.
>
>> Are you able to replicate those queries using the debuginfod-find CLI
>> tool? This is equivalent to the first query, I would expect it to
>> work:
>>
>> debuginfod-find executable f87c1d8cd2118209ef2350b22b187a64d705d6cd
>
> This is the build ID for my program, and this exists and is downloaded
> properly.
>
>> And this is equivalent to the second query, I would expect it to
>> fail:
>>
>> debuginfod-find debuginfo 8cfa19934886748ff4603da8aa8fdb0c2402b8cf
>
> This is the build ID for the debuginfo for my local system's runtime
> linker /lib64/ld-linux-x86-64.so.2:
>
>> [separate-debug-file] find_separate_debug_file_by_buildid: end:
>> looking for separate debug info (build-id) for /lib64/ld-linux-x86-
>> 64.so.2 debuginfod_find_debuginfo
>> 8cfa19934886748ff4603da8aa8fdb0c2402b8cf
>
> This doesn't exist in my debuginfod server. It might be nice to have
> debuginfo for the runtime linker, but I've never had it for any of my
> debugging sessions, because users very rarely install it on their
> systems, and it's not been a problem.
>
> Even if I wanted the debuginfo for the runtime linker, things have
> already gone awry here because GDB is loading my LOCAL SYSTEM'S runtime
> linker, when instead it should have downloaded the core file's runtime
> linker which is a different file with a different build ID.
To me, this is the biggest clue to what's going on here. I think GDB is
failing to find the build-ids within the core file for some reason.
Without a build-id all GDB has to operate on is the name of the shared
library. If your local shared library has the same name then GDB will
try to load that, and if the local file has no debug information, GDB
will request the associated debug information from debuginfod. Which is
what appears to happen here.
If I copy a core file from one of my machines to a totally different OS
version VM, and then try to load it into GDB, GDB finds the build-id and
refuses to load the local shared library.
Given that elf utils manages to read the build-ids from the core file
then I'm not sure what the problem is, but it feels like it must be a
GDB issue.
Unfortunately, there's no debug flag which reports on GDB as it parses
the build-ids from the core file. But the patch below which applies to
gdb-17-branch adds a new 'set debug core-load on' command, with this you
should be able to:
(gdb) set debug core-load on
(gdb) core-file ~/core.54313
[core-load] build_file_mappings: enter
[core-load] operator(): start = 0x400000, end = 0x407000, filename = /some/program, build-id = a004xxxx178xxxx78xxxx6c6cxxxx800df88xxxx
[core-load] operator(): start = 0x407000, end = 0x41e000, filename = /some/program, build-id = NONE
[core-load] operator(): start = 0x41e000, end = 0x427000, filename = /some/program, build-id = NONE
[core-load] operator(): start = 0x428000, end = 0x429000, filename = /some/program, build-id = NONE
You get one line like the above for each segment mapped from a core file
into the memory image, so you should expect to see most filenames
repeated multiple times. However, only one line for a given filename
will have a build-id associated with it, this is the segment that also
contains the build-id. If *no* lines for a given filename have a
build-id, then GDB didn't find a build-id for that filename.
If you were willing to apply this patch, rebuild GDB, and run this test
then this will split the problem space in half, is the problem GDB
reading the build-id from the core file, or is the problem GDB not using
the build-id it has to lookup the files.
Thanks,
Andrew
---
diff --git i/gdb/corelow.c w/gdb/corelow.c
index 29eafe8bdfd..95dd837e06e 100644
--- i/gdb/corelow.c
+++ w/gdb/corelow.c
@@ -58,6 +58,29 @@
#define O_LARGEFILE 0
#endif
+/* When true emit 'core-load' debug messages. */
+
+static bool debug_core_load = false;
+
+/* Handle 'show debug core-load' command. */
+
+static void
+show_core_load_debug (struct ui_file *file, int from_tty,
+ struct cmd_list_element *c, const char *value)
+{
+ gdb_printf (file, _("Core-load debugging is %s.\n"), value);
+}
+
+/* Print a "core-load" debug statement. */
+
+#define core_load_debug_printf(fmt, ...) \
+ debug_prefixed_printf_cond (debug_core_load, "core-load", fmt, ##__VA_ARGS__)
+
+/* Print "core-load" enter/exit debug statements. */
+
+#define CORE_LOAD_SCOPED_DEBUG_ENTER_EXIT \
+ scoped_debug_enter_exit (debug_core_load, "core-load")
+
/* Forward declarations. */
static void core_target_open (const char *arg, int from_tty);
@@ -365,6 +388,8 @@ core_target::core_target ()
void
core_target::build_file_mappings ()
{
+ CORE_LOAD_SCOPED_DEBUG_ENTER_EXIT;
+
/* Type holding information about a single file mapped into the inferior
at the point when the core file was created. Associates a build-id
with the list of regions the file is mapped into. */
@@ -426,6 +451,14 @@ core_target::build_file_mappings ()
[&] (int num, ULONGEST start, ULONGEST end, ULONGEST file_ofs,
const char *filename, const bfd_build_id *build_id)
{
+
+ core_load_debug_printf ("start = 0x%s, end = 0x%s, filename = %s, build-id = %s",
+ phex_nz (start), phex_nz (end),
+ (filename == nullptr ? "NONE" : filename),
+ (build_id == nullptr
+ ? "NONE"
+ : build_id_to_string (build_id).c_str ()));
+
/* Architecture-specific read_core_mapping methods are expected to
weed out non-file-backed mappings. */
gdb_assert (filename != nullptr);
@@ -2175,4 +2208,13 @@ INIT_GDB_FILE (corelow)
maintenance_print_core_file_backed_mappings,
_("Print core file's file-backed mappings."),
&maintenanceprintlist);
+
+ /* Debug this files internals. */
+ add_setshow_boolean_cmd ("core-load", class_maintenance, &debug_core_load, _("\
+Set core-load debugging."), _("\
+Show core-load debugging."), _("\
+When on, core-load specific internal debugging is enabled."),
+ NULL,
+ show_core_load_debug,
+ &setdebuglist, &showdebuglist);
}
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
2026-03-09 15:36 ` Simon Marchi via Gdb
@ 2026-03-09 17:28 ` Andrew Burgess via Gdb
0 siblings, 0 replies; 18+ messages in thread
From: Andrew Burgess via Gdb @ 2026-03-09 17:28 UTC (permalink / raw)
To: Simon Marchi, psmith, Arsen Arsenović; +Cc: gdb
Simon Marchi via Gdb <gdb@sourceware.org> writes:
> On 3/9/26 9:57 AM, Paul Smith wrote:
>> On Sun, 2026-03-08 at 22:32 -0400, Simon Marchi wrote:
>>> I noticed a difference between the first debuginfod call (which
>>> succeeds) and the second one (that fails). The first one is
>>> debuginfod_find_executable and the second is
>>> debuginfod_find_debuginfo. Could it be important?
>>
>> I think this is not an issue.
>>
>>> Are you able to replicate those queries using the debuginfod-find CLI
>>> tool? This is equivalent to the first query, I would expect it to
>>> work:
>>>
>>> debuginfod-find executable f87c1d8cd2118209ef2350b22b187a64d705d6cd
>>
>> This is the build ID for my program, and this exists and is downloaded
>> properly.
>>
>>> And this is equivalent to the second query, I would expect it to
>>> fail:
>>>
>>> debuginfod-find debuginfo 8cfa19934886748ff4603da8aa8fdb0c2402b8cf
>>
>> This is the build ID for the debuginfo for my local system's runtime
>> linker /lib64/ld-linux-x86-64.so.2:
>
> Ah ok, I didn't catch that from your output, sorry.
>
>>> [separate-debug-file] find_separate_debug_file_by_buildid: end:
>>> looking for separate debug info (build-id) for /lib64/ld-linux-x86-
>>> 64.so.2 debuginfod_find_debuginfo
>>> 8cfa19934886748ff4603da8aa8fdb0c2402b8cf
>>
>> This doesn't exist in my debuginfod server. It might be nice to have
>> debuginfo for the runtime linker, but I've never had it for any of my
>> debugging sessions, because users very rarely install it on their
>> systems, and it's not been a problem.
>>
>> Even if I wanted the debuginfo for the runtime linker, things have
>> already gone awry here because GDB is loading my LOCAL SYSTEM'S runtime
>> linker, when instead it should have downloaded the core file's runtime
>> linker which is a different file with a different build ID.
>>
>>>>> ⚠️ warning: platform-specific solib_create_inferior_hook did not
>>>>> load initial shared libraries.
>>>
>>> GDB still ends up listing the shared libs, so it might be red
>>> herring. It is still curious though.
>>
>> The reason I suggest this might be related is that it seems to me that
>> once we reach this point, GDB has already started to do the wrong
>> thing. For example as above, it's use the local system's ld-linux.so
>> rather than downloading the core file's ld-linux.so.
>>
>> I would expect that I would see requests to the debuginfod server for
>> the shared libraries, including the runtime linker itself, but I don't
>> see any of that. It only tries to find the executable and the
>> debuginfo file for the local system's runtime linker, and it never
>> tries to find anything else.
>
> I would add a printf in core_target::build_file_mappings to print the
> mapped files and their (if present) build-ids.
>
> And then put a breakpoint or printf in solib_bfd_open, to see when GDB
> tries to open the files for the solibs. It might be that we blindly
> open the files from the host, and we could add some build-id checks to
> avoid that (and ask debuginfod instead).
This should be handled already in solib_map_sections. Initially we open
a local file based on the shared library filename, but then we call
core_target_find_mapped_file which looks up the file based on the
filename and a representative address mapped within the shared library,
and returns some data that includes the build-id.
We the compare the build-id for the local file with that obtained from
the core file. If they don't match we close the local file we initially
opened, and then try to find a suitable file based on the build-id.
Or if there was no local file to open, then we also do the lookup by
build-id path.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
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
0 siblings, 1 reply; 18+ messages in thread
From: Paul Smith via Gdb @ 2026-03-09 20:32 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb
On Mon, 2026-03-09 at 16:57 +0000, Andrew Burgess wrote:
> Unfortunately, there's no debug flag which reports on GDB as it
> parses the build-ids from the core file. But the patch below which
> applies to gdb-17-branch adds a new 'set debug core-load on' command,
> with this you should be able to:
>
> (gdb) set debug core-load on
> (gdb) core-file ~/core.54313
> [core-load] build_file_mappings: enter
> [core-load] operator(): start = 0x400000, end = 0x407000,
> filename = /some/program, build-id =
> a004xxxx178xxxx78xxxx6c6cxxxx800df88xxxx
> [core-load] operator(): start = 0x407000, end = 0x41e000,
> filename = /some/program, build-id = NONE
> [core-load] operator(): start = 0x41e000, end = 0x427000,
> filename = /some/program, build-id = NONE
> [core-load] operator(): start = 0x428000, end = 0x429000,
> filename = /some/program, build-id = NONE
Ah, this is very useful. Unfortunately it leads me to this discovery;
the only output I get from this is:
(gdb) core-file /data/psh13/tmp/core
[core-load] build_file_mappings: enter
[core-load] build_file_mappings: exit
Apparently the executable is handled separately, since that is looked
up immediately afterwards (when setting DEBUGINFOD_VERBOSE=9):
> debuginfod_find_executable f87c1d8cd2118209ef2350b22b187a64d705d6cd
> server urls "http://debuginfod:8002"
> checking build-id
> checking cache dir /home/pds/.cache/debuginfod_client
> found
> /home/pds/.cache/debuginfod_client/f87c1d8cd2118209ef2350b22b187a64d7
> 05d6cd/hdr-executable (bytes=55)
> found
> /home/pds/.cache/debuginfod_client/f87c1d8cd2118209ef2350b22b187a64d7
> 05d6cd/executable (fd=14)
> Reading symbols from
> /home/pds/.cache/debuginfod_client/f87c1d8cd2118209ef2350b22b187a64d7
> 05d6cd/executable...
However, this is very good info, I will proceed to try to figure out
why eu-unstrip etc. can find the build ID values, but GDB cannot.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
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
2026-03-10 14:20 ` Andrew Burgess via Gdb
0 siblings, 2 replies; 18+ messages in thread
From: Paul Smith via Gdb @ 2026-03-09 21:19 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb
On Mon, 2026-03-09 at 16:32 -0400, Paul Smith via Gdb wrote:
> Ah, this is very useful. Unfortunately it leads me to this
> discovery;
> the only output I get from this is:
>
> (gdb) core-file /data/psh13/tmp/core
> [core-load] build_file_mappings: enter
> [core-load] build_file_mappings: exit
More debugging shows that linux_read_core_file_mappings() is returning
early due to this:
/* It's not required that the NT_FILE note exists, so return silently
if it's not found. Beyond this point though, we'll complain
if problems are found. */
asection *section = bfd_get_section_by_name (cbfd, ".note.linuxcore.file");
if (section == nullptr)
return;
(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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
2026-03-09 21:19 ` Paul Smith via Gdb
@ 2026-03-10 9:12 ` Mark Wielaard
2026-03-10 14:20 ` Andrew Burgess via Gdb
1 sibling, 0 replies; 18+ messages in thread
From: Mark Wielaard @ 2026-03-10 9:12 UTC (permalink / raw)
To: psmith; +Cc: Andrew Burgess, gdb
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
2026-03-09 21:19 ` Paul Smith via Gdb
2026-03-10 9:12 ` Mark Wielaard
@ 2026-03-10 14:20 ` Andrew Burgess via Gdb
2026-03-10 17:12 ` Paul Smith via Gdb
1 sibling, 1 reply; 18+ messages in thread
From: Andrew Burgess via Gdb @ 2026-03-10 14:20 UTC (permalink / raw)
To: psmith; +Cc: gdb
Paul Smith <psmith@gnu.org> writes:
> On Mon, 2026-03-09 at 16:32 -0400, Paul Smith via Gdb wrote:
>> Ah, this is very useful. Unfortunately it leads me to this
>> discovery;
>> the only output I get from this is:
>>
>> (gdb) core-file /data/psh13/tmp/core
>> [core-load] build_file_mappings: enter
>> [core-load] build_file_mappings: exit
>
> More debugging shows that linux_read_core_file_mappings() is returning
> early due to this:
>
> /* It's not required that the NT_FILE note exists, so return silently
> if it's not found. Beyond this point though, we'll complain
> if problems are found. */
> asection *section = bfd_get_section_by_name (cbfd, ".note.linuxcore.file");
> if (section == nullptr)
> return;
>
> (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.
Attached below is a **VERY** rough patch which might get things going
for you. This patch applies on gdb-17-branch and includes the previous
changes I sent, so you should probably revert them and then try this
patch to avoid conflicts.
Just to be clear what this is: this is a proof of concept. A very,
very, rough first cut. It has had minimal testing (just core file
related tests from the testsuite), and I've given no real though to
structure, performance, or improving the naming of functions or
variables as things have changed.
With that said, what's actually happening here? GDB uses the same
technique as elfutils (thanks for the info Mark) for finding the
build-ids; for every LOAD segment we treat this as if it were the start
of an ELF, and try to find the build-id. For those LOAD segments that
actually represent the start of an ELF, this will work.
As you spotted, GDB only does this if the NT_FILE note exists, that's
because we link the filename to the build-id. And historically, the
only way we could lookup the build-id for a shared library was via the
filename, so storing information about mappings without filenames was
pointless.
However, I recently reworked a lot of the code in this area, and (I
think) improved things. One case that interested me was shared
libraries with alternative names via symlinks. The filename stored in
the NT_FILE is the absolute filename, while the shared library name will
usually be the symlink name (if that's how the library was loaded).
This meant that GDB couldn't just match the shared library name to the
NT_FILE filename.
Now GDB used to try and work around this by also matching via the
libraries SONAME attribute.
But when I was working on this I ran into libraries that didn't have the
SONAME attribute, and so GDB would fail to figure out the build-id for
the shared library.
So in addition to keeping the previous lookup, I also added an address
to build-id map. Now, when libraries try to find the required build-id,
not only do we try the filename lookup, but we can also take an address
which we know is within the library, and look to see if we have a
build-id for that address, this filled the gap for libraries without a
SONAME attribute.
But, what remained is that all of the lookup data structures, the
filename to build-id, the soname to build-id, and the address to
build-id maps, are only created for mappings which are covered by
NT_FILE.
And that brings us to this patch. In the linux-tdep code, after
processing the NT_FILE (or if it's missing), I walk the segment table
looking for LOAD segments. If there was no NT_FILE entry for the same
address then I create an anonymous mapping. This mapping is passed back
to corelow.c.
In corelow.c the anonymous mapping is used to add additional entries
into the address to build-id mapping table.
Now, when we try to load a shared library, we try the filename based
lookups as before, but don't find anything. Then we try the address to
build-id lookup and now we find a match.
Anyway. Feel free to give this a go and let me know if it does what you
need. If this resolves the problems you're having then I'll clean this
code up and submit it for inclusion.
Thanks,
Andrew
---
diff --git i/gdb/corelow.c w/gdb/corelow.c
index 29eafe8bdfd..d9c19315adf 100644
--- i/gdb/corelow.c
+++ w/gdb/corelow.c
@@ -58,6 +58,29 @@
#define O_LARGEFILE 0
#endif
+/* When true emit 'core-load' debug messages. */
+
+static bool debug_core_load = false;
+
+/* Handle 'show debug core-load' command. */
+
+static void
+show_core_load_debug (struct ui_file *file, int from_tty,
+ struct cmd_list_element *c, const char *value)
+{
+ gdb_printf (file, _("Core-load debugging is %s.\n"), value);
+}
+
+/* Print a "core-load" debug statement. */
+
+#define core_load_debug_printf(fmt, ...) \
+ debug_prefixed_printf_cond (debug_core_load, "core-load", fmt, ##__VA_ARGS__)
+
+/* Print "core-load" enter/exit debug statements. */
+
+#define CORE_LOAD_SCOPED_DEBUG_ENTER_EXIT \
+ scoped_debug_enter_exit (debug_core_load, "core-load")
+
/* Forward declarations. */
static void core_target_open (const char *arg, int from_tty);
@@ -365,6 +388,8 @@ core_target::core_target ()
void
core_target::build_file_mappings ()
{
+ CORE_LOAD_SCOPED_DEBUG_ENTER_EXIT;
+
/* Type holding information about a single file mapped into the inferior
at the point when the core file was created. Associates a build-id
with the list of regions the file is mapped into. */
@@ -410,6 +435,8 @@ core_target::build_file_mappings ()
/* All files mapped into the core file. The key is the filename. */
gdb::unordered_map<std::string, mapped_file> mapped_files;
+ std::vector<mapped_file> mapped_anon_regions;
+
/* See linux_read_core_file_mappings() in linux-tdep.c for an example
read_core_file_mappings method. */
gdbarch_read_core_file_mappings (m_core_gdbarch,
@@ -426,25 +453,39 @@ core_target::build_file_mappings ()
[&] (int num, ULONGEST start, ULONGEST end, ULONGEST file_ofs,
const char *filename, const bfd_build_id *build_id)
{
- /* Architecture-specific read_core_mapping methods are expected to
- weed out non-file-backed mappings. */
- gdb_assert (filename != nullptr);
- /* Add this mapped region to the data for FILENAME. */
- mapped_file &file_data = mapped_files[filename];
- file_data.regions.emplace_back (start, end, file_ofs);
- if (build_id != nullptr && !file_data.ignore_build_id_p)
+ core_load_debug_printf ("start = 0x%s, end = 0x%s, filename = %s, build-id = %s",
+ phex_nz (start), phex_nz (end),
+ (filename == nullptr ? "NONE" : filename),
+ (build_id == nullptr
+ ? "NONE"
+ : build_id_to_string (build_id).c_str ()));
+
+ if (filename != nullptr)
{
- if (file_data.build_id == nullptr)
- file_data.build_id = build_id;
- else if (!build_id_equal (build_id, file_data.build_id))
+ /* Add this mapped region to the data for FILENAME. */
+ mapped_file &file_data = mapped_files[filename];
+ file_data.regions.emplace_back (start, end, file_ofs);
+ if (build_id != nullptr && !file_data.ignore_build_id_p)
{
- warning (_("Multiple build-ids found for %ps"),
- styled_string (file_name_style.style (), filename));
- file_data.build_id = nullptr;
- file_data.ignore_build_id_p = true;
+ if (file_data.build_id == nullptr)
+ file_data.build_id = build_id;
+ else if (!build_id_equal (build_id, file_data.build_id))
+ {
+ warning (_("Multiple build-ids found for %ps"),
+ styled_string (file_name_style.style (), filename));
+ file_data.build_id = nullptr;
+ file_data.ignore_build_id_p = true;
+ }
}
}
+ else if (build_id != nullptr)
+ {
+ mapped_file data = { .build_id = build_id };
+ gdb_assert (file_ofs == 0);
+ data.regions.emplace_back (start, end, file_ofs);
+ mapped_anon_regions.push_back (std::move (data));
+ }
});
/* Get the build-id of the core file. */
@@ -453,6 +494,8 @@ core_target::build_file_mappings ()
for (const auto &[filename, file_data] : mapped_files)
{
+ core_load_debug_printf ("checking mapped file: %s", filename.c_str ());
+
/* If this mapped file has the same build-id as was discovered for
the core-file itself, then we assume this is the main
executable. Record the filename as we can use this later. */
@@ -468,6 +511,11 @@ core_target::build_file_mappings ()
gdb::unique_xmalloc_ptr<char> expanded_fname
= exec_file_find (filename.c_str (), nullptr);
+ core_load_debug_printf ("expanded filename: %s",
+ (expanded_fname.get () == nullptr
+ ? "NONE"
+ : expanded_fname.get ()));
+
bool build_id_mismatch = false;
if (expanded_fname != nullptr && file_data.build_id != nullptr)
{
@@ -491,6 +539,11 @@ core_target::build_file_mappings ()
= build_id_bfd_get (tmp_bfd.get ());
if (!build_id_equal (found, file_data.build_id))
build_id_mismatch = true;
+
+ core_load_debug_printf ("for expanded filename, build-id is %s%s",
+ build_id_to_string (found).c_str (),
+ (build_id_mismatch
+ ? "\t[mismatched]" : ""));
}
}
@@ -522,6 +575,8 @@ core_target::build_file_mappings ()
struct bfd *b = bfd_openr (expanded_fname.get (), "binary");
gdb_assert (b != nullptr);
abfd = gdb_bfd_ref_ptr::new_reference (b);
+ core_load_debug_printf
+ ("found a suitable objfile based on build-id");
}
}
@@ -533,6 +588,8 @@ core_target::build_file_mappings ()
|| abfd == nullptr
|| !bfd_check_format (abfd.get (), bfd_object))
{
+ core_load_debug_printf ("failed to find a suitable objfile");
+
/* If ABFD was opened, but the wrong format, close it now. */
abfd = nullptr;
@@ -652,12 +709,40 @@ core_target::build_file_mappings ()
soname = gdb_bfd_read_elf_soname (actual_filename);
}
+ core_load_debug_printf ("recording file for soname lookup");
+ core_load_debug_printf (" soname = %s",
+ (soname.get () == nullptr
+ ? "NONE" : soname.get ()));
+ core_load_debug_printf (" actual filename = %s",
+ (actual_filename == nullptr
+ ? "NONE" : actual_filename));
+
m_mapped_file_info.add (soname.get (), filename.c_str (),
actual_filename, std::move (ranges),
file_data.build_id);
}
}
+ for (auto &r : mapped_anon_regions)
+ {
+ std::vector<mem_range> ranges;
+ for (const mapped_file::region ®ion : r.regions)
+ ranges.emplace_back (region.start, region.end - region.start);
+
+ normalize_mem_ranges (&ranges);
+
+ gdb_assert (r.build_id != nullptr);
+
+ core_load_debug_printf ("recording anon region for build-id %s",
+ build_id_to_string (r.build_id).c_str ());
+
+ m_mapped_file_info.add (nullptr, nullptr, nullptr, std::move (ranges),
+ r.build_id);
+ }
+
+ core_load_debug_printf ("expected executable name: %s",
+ m_expected_exec_filename.c_str ());
+
normalize_mem_ranges (&m_core_unavailable_mappings);
}
@@ -2026,7 +2111,6 @@ mapped_file_info::add (const char *soname,
const bfd_build_id *build_id)
{
gdb_assert (build_id != nullptr);
- gdb_assert (expected_filename != nullptr);
if (soname != nullptr)
{
@@ -2050,9 +2134,13 @@ mapped_file_info::add (const char *soname,
parsed, we group the build-id information based on the file name. As
a consequence, we should see each EXPECTED_FILENAME value exactly
once. This means that each insertion should always succeed. */
- const auto inserted
- = m_filename_to_build_id_map.emplace (expected_filename, build_id).second;
- gdb_assert (inserted);
+ if (expected_filename != nullptr)
+ {
+ const auto inserted
+ = m_filename_to_build_id_map.emplace (expected_filename,
+ build_id).second;
+ gdb_assert (inserted);
+ }
/* Setup the reverse build-id to file name map. */
if (actual_filename != nullptr)
@@ -2164,7 +2252,16 @@ core_target_find_mapped_file (const char *filename,
if (targ == nullptr || current_program_space->cbfd.get () == nullptr)
return {};
- return targ->lookup_mapped_file_info (filename, addr);
+ std::optional <core_target_mapped_file_info> result
+ = targ->lookup_mapped_file_info (filename, addr);
+
+ core_load_debug_printf ("filename = %s, addr = %s%s",
+ (filename == nullptr ? "NONE" : filename),
+ (addr.has_value ()
+ ? core_addr_to_string_nz (addr.value ()) : "NONE"),
+ (result.has_value () ? "\t[found]" : ""));
+
+ return result;
}
INIT_GDB_FILE (corelow)
@@ -2175,4 +2272,13 @@ INIT_GDB_FILE (corelow)
maintenance_print_core_file_backed_mappings,
_("Print core file's file-backed mappings."),
&maintenanceprintlist);
+
+ /* Debug this files internals. */
+ add_setshow_boolean_cmd ("core-load", class_maintenance, &debug_core_load, _("\
+Set core-load debugging."), _("\
+Show core-load debugging."), _("\
+When on, core-load specific internal debugging is enabled."),
+ NULL,
+ show_core_load_debug,
+ &setdebuglist, &showdebuglist);
}
diff --git i/gdb/linux-tdep.c w/gdb/linux-tdep.c
index f07f9879614..27443f7fb4b 100644
--- i/gdb/linux-tdep.c
+++ w/gdb/linux-tdep.c
@@ -1136,70 +1136,7 @@ linux_read_core_file_mappings
/* Ensure that ULONGEST is big enough for reading 64-bit core files. */
static_assert (sizeof (ULONGEST) >= 8);
- /* It's not required that the NT_FILE note exists, so return silently
- if it's not found. Beyond this point though, we'll complain
- if problems are found. */
- asection *section = bfd_get_section_by_name (cbfd, ".note.linuxcore.file");
- if (section == nullptr)
- return;
-
- unsigned int addr_size_bits = gdbarch_addr_bit (gdbarch);
- unsigned int addr_size = addr_size_bits / 8;
- size_t note_size = bfd_section_size (section);
-
- if (note_size < 2 * addr_size)
- {
- warning (_("malformed core note - too short for header"));
- return;
- }
-
- gdb::byte_vector contents (note_size);
- if (!bfd_get_section_contents (cbfd, section, contents.data (), 0,
- note_size))
- {
- warning (_("could not get core note contents"));
- return;
- }
-
- gdb_byte *descdata = contents.data ();
- char *descend = (char *) descdata + note_size;
-
- if (descdata[note_size - 1] != '\0')
- {
- warning (_("malformed note - does not end with \\0"));
- return;
- }
-
- ULONGEST count = bfd_get (addr_size_bits, cbfd, descdata);
- descdata += addr_size;
-
- ULONGEST page_size = bfd_get (addr_size_bits, cbfd, descdata);
- descdata += addr_size;
-
- if (note_size < 2 * addr_size + count * 3 * addr_size)
- {
- warning (_("malformed note - too short for supplied file count"));
- return;
- }
-
- char *filenames = (char *) descdata + count * 3 * addr_size;
-
- /* Make sure that the correct number of filenames exist. Complain
- if there aren't enough or are too many. */
- char *f = filenames;
- for (int i = 0; i < count; i++)
- {
- if (f >= descend)
- {
- warning (_("malformed note - filename area is too small"));
- return;
- }
- f += strnlen (f, descend - f) + 1;
- }
- /* Complain, but don't return early if the filename area is too big. */
- if (f != descend)
- warning (_("malformed note - filename area is too big"));
-
+ /* Get build-id from every loadable section that can provide one. */
const bfd_build_id *orig_build_id = cbfd->build_id;
gdb::unordered_map<ULONGEST, const bfd_build_id *> vma_map;
@@ -1216,26 +1153,145 @@ linux_read_core_file_mappings
}
cbfd->build_id = orig_build_id;
- pre_loop_cb (count);
- for (int i = 0; i < count; i++)
+ /* Vector to collect proc mappings. */
+ struct proc_mapping
+ {
+ int num;
+ ULONGEST start;
+ ULONGEST end;
+ ULONGEST file_ofs;
+ const char *filename;
+ const bfd_build_id *build_id;
+ };
+ std::vector<struct proc_mapping> proc_mappings;
+
+ /* The start address of each mapping. */
+ gdb::unordered_set<ULONGEST> mapping_start_addr_set;
+
+ /* It's not required that the NT_FILE note exists, so return silently
+ if it's not found. Beyond this point though, we'll complain
+ if problems are found. */
+ asection *section = bfd_get_section_by_name (cbfd, ".note.linuxcore.file");
+ if (section != nullptr)
{
- ULONGEST start = bfd_get (addr_size_bits, cbfd, descdata);
- descdata += addr_size;
- ULONGEST end = bfd_get (addr_size_bits, cbfd, descdata);
- descdata += addr_size;
- ULONGEST file_ofs = bfd_get (addr_size_bits, cbfd, descdata) * page_size;
- descdata += addr_size;
- char * filename = filenames;
- filenames += strlen ((char *) filenames) + 1;
- const bfd_build_id *build_id = nullptr;
- auto vma_map_it = vma_map.find (start);
+ unsigned int addr_size_bits = gdbarch_addr_bit (gdbarch);
+ unsigned int addr_size = addr_size_bits / 8;
+ size_t note_size = bfd_section_size (section);
- if (vma_map_it != vma_map.end ())
- build_id = vma_map_it->second;
+ if (note_size < 2 * addr_size)
+ {
+ warning (_("malformed core note - too short for header"));
+ return;
+ }
- loop_cb (i, start, end, file_ofs, filename, build_id);
+ gdb::byte_vector contents (note_size);
+ if (!bfd_get_section_contents (cbfd, section, contents.data (), 0,
+ note_size))
+ {
+ warning (_("could not get core note contents"));
+ return;
+ }
+
+ gdb_byte *descdata = contents.data ();
+ char *descend = (char *) descdata + note_size;
+
+ if (descdata[note_size - 1] != '\0')
+ {
+ warning (_("malformed note - does not end with \\0"));
+ return;
+ }
+
+ ULONGEST count = bfd_get (addr_size_bits, cbfd, descdata);
+ descdata += addr_size;
+
+ ULONGEST page_size = bfd_get (addr_size_bits, cbfd, descdata);
+ descdata += addr_size;
+
+ if (note_size < 2 * addr_size + count * 3 * addr_size)
+ {
+ warning (_("malformed note - too short for supplied file count"));
+ return;
+ }
+
+ char *filenames = (char *) descdata + count * 3 * addr_size;
+
+ /* Make sure that the correct number of filenames exist. Complain
+ if there aren't enough or are too many. */
+ char *f = filenames;
+ for (int i = 0; i < count; i++)
+ {
+ if (f >= descend)
+ {
+ warning (_("malformed note - filename area is too small"));
+ return;
+ }
+ f += strnlen (f, descend - f) + 1;
+ }
+ /* Complain, but don't return early if the filename area is too big. */
+ if (f != descend)
+ warning (_("malformed note - filename area is too big"));
+
+ /* Collect proc mappings. */
+ for (int i = 0; i < count; i++)
+ {
+ struct proc_mapping m = { .num = i };
+ m.start = bfd_get (addr_size_bits, cbfd, descdata);
+ descdata += addr_size;
+ m.end = bfd_get (addr_size_bits, cbfd, descdata);
+ descdata += addr_size;
+ m.file_ofs = bfd_get (addr_size_bits, cbfd, descdata) * page_size;
+ descdata += addr_size;
+ m.filename = filenames;
+ filenames += strlen ((char *) filenames) + 1;
+
+ m.build_id = nullptr;
+ auto vma_map_it = vma_map.find (m.start);
+ if (vma_map_it != vma_map.end ())
+ m.build_id = vma_map_it->second;
+
+ proc_mappings.push_back (m);
+ mapping_start_addr_set.insert (m.start);
+ }
}
+
+ for (bfd_section *sec = cbfd->sections; sec != nullptr; sec = sec->next)
+ {
+ /* The NUM field is never used, this should probably just be
+ removed. */
+ struct proc_mapping m = { .num = -1 };
+
+ bfd_vma start = bfd_section_vma (sec);
+
+ if (mapping_start_addr_set.contains (start))
+ continue;
+
+ m.start = start;
+ m.end = start + bfd_section_size (sec);
+ m.file_ofs = 0;
+ m.filename = nullptr;
+
+ m.build_id = nullptr;
+ auto vma_map_it = vma_map.find (m.start);
+ if (vma_map_it != vma_map.end ())
+ m.build_id = vma_map_it->second;
+
+ proc_mappings.push_back (m);
+ mapping_start_addr_set.insert (m.start);
+ }
+
+ /* Sort proc mappings. */
+ std::sort (proc_mappings.begin (), proc_mappings.end (),
+ [] (const proc_mapping &a, const proc_mapping &b)
+ {
+ return a.start < b.start;
+ });
+
+ pre_loop_cb (proc_mappings.size ());
+
+ /* Call loop_cb with sorted proc mappings. */
+ for (const auto &m : proc_mappings)
+ loop_cb (m.num, m.start, m.end, m.file_ofs, m.filename, m.build_id);
}
/* Implement "info proc mappings" for corefile CBFD. */
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
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
0 siblings, 1 reply; 18+ messages in thread
From: Paul Smith via Gdb @ 2026-03-10 17:12 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb
On Tue, 2026-03-10 at 14:20 +0000, Andrew Burgess wrote:
> Attached below is a **VERY** rough patch which might get things going
> for you. This patch applies on gdb-17-branch and includes the
> previous changes I sent, so you should probably revert them and then
> try this patch to avoid conflicts.
Wow I did not expect such a quick response! However, your patch works
for me (I fully grok your admonitions about this being a rough draft).
I did see odd output related to operator() but maybe it's not odd to
you :)
Here's the full output from:
gdb -c core -batch -ex 'info shared'
Note I believe it is actually true that my debuginfod server doesn't
have the right file for the libgcc_s.so file, for whatever reason, so
that's not an issue with GDB.
[core-load] build_file_mappings: enter
[core-load] operator(): start = 0x0, end = 0xc104, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x200000, end = 0x201000, filename = NONE, build-id = f87c1d8cd2118209ef2350b22b187a64d705d6cd
[core-load] operator(): start = 0x201000, end = 0xe71000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0xe71000, end = 0x210a000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x210a000, end = 0x21f6000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x21f6000, end = 0x2215000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x2215000, end = 0x2445000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f502be00000, end = 0x7f5683a00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5683b00000, end = 0x7f569c200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f569c300000, end = 0x7f5802e00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5802e80000, end = 0x7f59fe200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f59fe280000, end = 0x7f5a19400000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5a19480000, end = 0x7f5a21a00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5a21a80000, end = 0x7f5b79400000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5b79500000, end = 0x7f5c50400000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5c50580000, end = 0x7f5ccf600000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5ccfef9000, end = 0x7f5ccff00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5cd0200000, end = 0x7f5cf9400000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5cf9585000, end = 0x7f5ee3c00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5ee45fc000, end = 0x7f5ee4600000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5ee4600000, end = 0x7f5ee4a00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5ee4bff000, end = 0x7f5ee4dff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5ee55fc000, end = 0x7f5ee5600000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5ee5600000, end = 0x7f5ee5800000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5ee61fc000, end = 0x7f5ee6200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5ee6200000, end = 0x7f5ee6600000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5ee67ff000, end = 0x7f5ee69ff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5ee71fc000, end = 0x7f5ee7200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5ee7200000, end = 0x7f5ee7400000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5ee75ff000, end = 0x7f5ee77ff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5ee7ffc000, end = 0x7f5ee8000000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5ee8000000, end = 0x7f5ee8200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5ee8bfc000, end = 0x7f5ee8c00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5ee8c00000, end = 0x7f5eed000000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f5eed100000, end = 0x7f60a8e00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f60a8f00000, end = 0x7f6115200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6115280000, end = 0x7f6518800000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6518980000, end = 0x7f6694800000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6694900000, end = 0x7f6891a00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6891b00000, end = 0x7f69ec400000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f69ec585000, end = 0x7f6a67200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6a67580000, end = 0x7f6a95c00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6a96579000, end = 0x7f6a96580000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6a96580000, end = 0x7f6b4a600000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6b4a780000, end = 0x7f6be1c00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6be1d20000, end = 0x7f6c12c00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c135f8000, end = 0x7f6c135ff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c13df9000, end = 0x7f6c13e00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c13e00000, end = 0x7f6c14600000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c14ff8000, end = 0x7f6c14fff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c157f9000, end = 0x7f6c15800000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c15800000, end = 0x7f6c16000000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c169f8000, end = 0x7f6c169ff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c171f9000, end = 0x7f6c17200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c17200000, end = 0x7f6c17a00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c18378000, end = 0x7f6c1837f000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c18b79000, end = 0x7f6c18b80000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c18b83000, end = 0x7f6c2ae00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c2b7fa000, end = 0x7f6c2b7ff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c2bff9000, end = 0x7f6c2c000000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c2c000000, end = 0x7f6c2c800000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c2d1fa000, end = 0x7f6c2d1ff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c2d9f9000, end = 0x7f6c2da00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c2da00000, end = 0x7f6c2e200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c2ebfa000, end = 0x7f6c2ebff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c2f3f9000, end = 0x7f6c2f400000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6c2f400000, end = 0x7f6e4f800000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6e4f900000, end = 0x7f6f4b600000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f6f4b7ec000, end = 0x7f70ace00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f70ad7f9000, end = 0x7f70ad800000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f70ad82b000, end = 0x7f7acc800000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7accee9000, end = 0x7f7af0a00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7af0b00000, end = 0x7f7b0bc00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b0bd00000, end = 0x7f7b2c000000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b2c180000, end = 0x7f7b5e800000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b5f1fc000, end = 0x7f7b5f200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b5f200000, end = 0x7f7b5fe00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b607fb000, end = 0x7f7b607ff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b607ff000, end = 0x7f7b609ff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b611fc000, end = 0x7f7b61200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b61200000, end = 0x7f7b61400000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b615ff000, end = 0x7f7b617ff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b61ffc000, end = 0x7f7b62000000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b62000000, end = 0x7f7b62200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b623ff000, end = 0x7f7b625ff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b62dfc000, end = 0x7f7b62e00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b62e00000, end = 0x7f7b63000000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b639fb000, end = 0x7f7b639ff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b641fc000, end = 0x7f7b64200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b64214000, end = 0x7f7b65000000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b658e9000, end = 0x7f7b65900000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7b65900000, end = 0x7f7ba0200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7ba0280000, end = 0x7f7bc2600000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bc2700000, end = 0x7f7bce200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bcebf8000, end = 0x7f7bcebff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bcf3f9000, end = 0x7f7bcf400000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bcf400000, end = 0x7f7bcf800000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bd01fa000, end = 0x7f7bd0200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bd0200000, end = 0x7f7bd8000000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bd89f9000, end = 0x7f7bd8a00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bd8a00000, end = 0x7f7bd9200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bd9a7c000, end = 0x7f7bd9a7f000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bda27c000, end = 0x7f7bda280000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bda280000, end = 0x7f7bdce00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bdcffe000, end = 0x7f7bdd3fe000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bddbfb000, end = 0x7f7bddbff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bde3fc000, end = 0x7f7bde400000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bde400000, end = 0x7f7bde600000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bde7ff000, end = 0x7f7bde9ff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bdf1fc000, end = 0x7f7bdf200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bdf200000, end = 0x7f7bdf400000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7bdfdfb000, end = 0x7f7bdfdff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be05fc000, end = 0x7f7be0600000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be0600000, end = 0x7f7be0a00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be13fb000, end = 0x7f7be1400000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be1400000, end = 0x7f7be1800000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be21f9000, end = 0x7f7be2200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be2200000, end = 0x7f7be2600000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be2ffc000, end = 0x7f7be3000000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be3000000, end = 0x7f7be3400000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be3cfb000, end = 0x7f7be3d00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be3d00000, end = 0x7f7be4e00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be57fb000, end = 0x7f7be57ff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be57ff000, end = 0x7f7be59ff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be61ed000, end = 0x7f7be6200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be6200000, end = 0x7f7be6400000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be6dfa000, end = 0x7f7be6e00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be6e00000, end = 0x7f7be7200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be7bfa000, end = 0x7f7be7c00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be7c00000, end = 0x7f7be8000000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be89fc000, end = 0x7f7be8a00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be8a01000, end = 0x7f7be8e00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be97fa000, end = 0x7f7be9800000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f7be9800000, end = 0x7f9639800000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f963a5d9000, end = 0x7f963d200000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f963dbfc000, end = 0x7f963dc00000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f963dc00000, end = 0x7f963e400000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f963e400000, end = 0x7f963e401000, filename = NONE, build-id = b5fa5a9afce174ac5751cad3fcbfacbc10158cfd
[core-load] operator(): start = 0x7f963e401000, end = 0x7f963e428000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f963e428000, end = 0x7f963e59d000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f963e59d000, end = 0x7f963e5f5000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f963e5f5000, end = 0x7f963e5f9000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f963e5f9000, end = 0x7f963e5fb000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f963e5fb000, end = 0x7f963e608000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f963e725000, end = 0x7f963e726000, filename = NONE, build-id = 0f68df2ecc3bf901984fb285219026d67356bc58
[core-load] operator(): start = 0x7f963e726000, end = 0x7f963e732000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f963e732000, end = 0x7f963e7a2000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f963e7a2000, end = 0x7f963e7fe000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f963e7fe000, end = 0x7f963e7ff000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f963e7ff000, end = 0x7f963e800000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f963e800000, end = 0x7f963e801000, filename = NONE, build-id = fab6d29d039209ed2ee8bae1511c1d436a145cbd
[core-load] operator(): start = 0x7f963e801000, end = 0x7f964054f000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f964054f000, end = 0x7f9640550000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640600000, end = 0x7f9640601000, filename = NONE, build-id = b86ba1ea98524d1de7cd46a8f54f65633e280eeb
[core-load] operator(): start = 0x7f9640601000, end = 0x7f9640997000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640997000, end = 0x7f96409b2000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f96409b2000, end = 0x7f96409b3000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f96409b3000, end = 0x7f96409b8000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640a00000, end = 0x7f9640a01000, filename = NONE, build-id = c1ce8a211990184f5d7fe77d3b94ad0b64c85ec2
[core-load] operator(): start = 0x7f9640a01000, end = 0x7f9640dc8000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640dc9000, end = 0x7f9640ddc000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640ddc000, end = 0x7f9640dde000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640dde000, end = 0x7f9640ddf000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e14000, end = 0x7f9640e15000, filename = NONE, build-id = fe8903ee76261ccca26c0f75daa1da637a93f37b
[core-load] operator(): start = 0x7f9640e15000, end = 0x7f9640e17000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e17000, end = 0x7f9640e29000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e29000, end = 0x7f9640e2c000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e2c000, end = 0x7f9640e2d000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e2d000, end = 0x7f9640e2e000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e2e000, end = 0x7f9640e33000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e33000, end = 0x7f9640e34000, filename = NONE, build-id = 948b8cd7e0fb7551a2621b33b2964fc54a0c87c8
[core-load] operator(): start = 0x7f9640e34000, end = 0x7f9640e35000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e35000, end = 0x7f9640e36000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e36000, end = 0x7f9640e37000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e37000, end = 0x7f9640e38000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e38000, end = 0x7f9640e3a000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e3a000, end = 0x7f9640e3b000, filename = NONE, build-id = 3956610e51d2f93ce7eacd9c3378f0dcd0600c46
[core-load] operator(): start = 0x7f9640e3b000, end = 0x7f9640e3c000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e3c000, end = 0x7f9640e3d000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e3d000, end = 0x7f9640e3e000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e3e000, end = 0x7f9640e3f000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e3f000, end = 0x7f9640e40000, filename = NONE, build-id = 5244013d53cae3a5dc074be62e8fdf8ae6bc4efa
[core-load] operator(): start = 0x7f9640e40000, end = 0x7f9640e41000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e41000, end = 0x7f9640e46000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e46000, end = 0x7f9640e47000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e47000, end = 0x7f9640e48000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e54000, end = 0x7f9640e56000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e56000, end = 0x7f9640e57000, filename = NONE, build-id = d8fc7cbd7ef0b72e5f077107a4181e76f4f5c88f
[core-load] operator(): start = 0x7f9640e57000, end = 0x7f9640e58000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e58000, end = 0x7f9640e7f000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e7f000, end = 0x7f9640e8a000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e8a000, end = 0x7f9640e8c000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7f9640e8c000, end = 0x7f9640e8e000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7ffff858c000, end = 0x7ffff8594000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7ffff85e0000, end = 0x7ffff85e4000, filename = NONE, build-id = NONE
[core-load] operator(): start = 0x7ffff85e4000, end = 0x7ffff85e6000, filename = NONE, build-id = bf619d454c75501884ae152c241f1f2c2039f532
[core-load] build_file_mappings: recording anon region for build-id f87c1d8cd2118209ef2350b22b187a64d705d6cd
[core-load] build_file_mappings: recording anon region for build-id b5fa5a9afce174ac5751cad3fcbfacbc10158cfd
[core-load] build_file_mappings: recording anon region for build-id 0f68df2ecc3bf901984fb285219026d67356bc58
[core-load] build_file_mappings: recording anon region for build-id fab6d29d039209ed2ee8bae1511c1d436a145cbd
[core-load] build_file_mappings: recording anon region for build-id b86ba1ea98524d1de7cd46a8f54f65633e280eeb
[core-load] build_file_mappings: recording anon region for build-id c1ce8a211990184f5d7fe77d3b94ad0b64c85ec2
[core-load] build_file_mappings: recording anon region for build-id fe8903ee76261ccca26c0f75daa1da637a93f37b
[core-load] build_file_mappings: recording anon region for build-id 948b8cd7e0fb7551a2621b33b2964fc54a0c87c8
[core-load] build_file_mappings: recording anon region for build-id 3956610e51d2f93ce7eacd9c3378f0dcd0600c46
[core-load] build_file_mappings: recording anon region for build-id 5244013d53cae3a5dc074be62e8fdf8ae6bc4efa
[core-load] build_file_mappings: recording anon region for build-id d8fc7cbd7ef0b72e5f077107a4181e76f4f5c88f
[core-load] build_file_mappings: recording anon region for build-id bf619d454c75501884ae152c241f1f2c2039f532
[core-load] build_file_mappings: expected executable name:
[core-load] build_file_mappings: exit
[core-load] core_target_find_mapped_file: filename = NONE, addr = 0xe73000
Reading symbols from /home/pds/.cache/debuginfod_client/f87c1d8cd2118209ef2350b22b187a64d705d6cd/executable...
warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
[core-load] core_target_find_mapped_file: filename = /opt/lib64/libicui18n.so.75, addr = 0x7f9640a00000 [found]
[core-load] core_target_find_mapped_file: filename = /opt/lib64/libicuuc.so.75, addr = 0x7f9640600000 [found]
[core-load] core_target_find_mapped_file: filename = /opt/lib64/libicudata.so.75, addr = 0x7f963e800000 [found]
[core-load] core_target_find_mapped_file: filename = /lib64/libuuid.so.1, addr = 0x7f9640e3f000 [found]
[core-load] core_target_find_mapped_file: filename = /lib64/libdl.so.2, addr = 0x7f9640e3a000 [found]
[core-load] core_target_find_mapped_file: filename = /lib64/libm.so.6, addr = 0x7f963e725000 [found]
[core-load] core_target_find_mapped_file: filename = /lib64/libpthread.so.0, addr = 0x7f9640e33000 [found]
[core-load] core_target_find_mapped_file: filename = /lib64/libc.so.6, addr = 0x7f963e400000 [found]
[core-load] core_target_find_mapped_file: filename = /lib64/ld-linux-x86-64.so.2, addr = 0x7f9640e56000 [found]
[core-load] core_target_find_mapped_file: filename = /lib64/libgcc_s.so.1, addr = 0x7f9640e14000 [found]
warning: Could not load shared library symbols for /lib64/libgcc_s.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Reading symbols from /home/pds/.cache/debuginfod_client/c1ce8a211990184f5d7fe77d3b94ad0b64c85ec2/executable...
Reading symbols from /home/pds/.cache/debuginfod_client/b86ba1ea98524d1de7cd46a8f54f65633e280eeb/executable...
Reading symbols from /home/pds/.cache/debuginfod_client/fab6d29d039209ed2ee8bae1511c1d436a145cbd/executable...
(No debugging symbols found in /home/pds/.cache/debuginfod_client/fab6d29d039209ed2ee8bae1511c1d436a145cbd/executable)
Reading symbols from /home/pds/.cache/debuginfod_client/5244013d53cae3a5dc074be62e8fdf8ae6bc4efa/executable...
Reading symbols from .gnu_debugdata for /home/pds/.cache/debuginfod_client/5244013d53cae3a5dc074be62e8fdf8ae6bc4efa/executable...
(No debugging symbols found in .gnu_debugdata for /home/pds/.cache/debuginfod_client/5244013d53cae3a5dc074be62e8fdf8ae6bc4efa/executable)
Reading symbols from /home/pds/.cache/debuginfod_client/3956610e51d2f93ce7eacd9c3378f0dcd0600c46/executable...
Reading symbols from .gnu_debugdata for /home/pds/.cache/debuginfod_client/3956610e51d2f93ce7eacd9c3378f0dcd0600c46/executable...
(No debugging symbols found in .gnu_debugdata for /home/pds/.cache/debuginfod_client/3956610e51d2f93ce7eacd9c3378f0dcd0600c46/executable)
Reading symbols from /home/pds/.cache/debuginfod_client/0f68df2ecc3bf901984fb285219026d67356bc58/executable...
Reading symbols from .gnu_debugdata for /home/pds/.cache/debuginfod_client/0f68df2ecc3bf901984fb285219026d67356bc58/executable...
(No debugging symbols found in .gnu_debugdata for /home/pds/.cache/debuginfod_client/0f68df2ecc3bf901984fb285219026d67356bc58/executable)
Reading symbols from /home/pds/.cache/debuginfod_client/948b8cd7e0fb7551a2621b33b2964fc54a0c87c8/executable...
Reading symbols from .gnu_debugdata for /home/pds/.cache/debuginfod_client/948b8cd7e0fb7551a2621b33b2964fc54a0c87c8/executable...
(No debugging symbols found in .gnu_debugdata for /home/pds/.cache/debuginfod_client/948b8cd7e0fb7551a2621b33b2964fc54a0c87c8/executable)
Reading symbols from /home/pds/.cache/debuginfod_client/b5fa5a9afce174ac5751cad3fcbfacbc10158cfd/executable...
(No debugging symbols found in /home/pds/.cache/debuginfod_client/b5fa5a9afce174ac5751cad3fcbfacbc10158cfd/executable)
Reading symbols from /home/pds/.cache/debuginfod_client/d8fc7cbd7ef0b72e5f077107a4181e76f4f5c88f/executable...
Reading symbols from system-supplied DSO at 0x7ffff85e4000...
(No debugging symbols found in system-supplied DSO at 0x7ffff85e4000)
Core was generated by `/opt/bin/myprogram'.
#0 0x0000000001fa11ca in WriteCompressedCoreDump ()
[Current thread is 1 (LWP 2184998)]
From To Syms Read Shared Object Library
0x00007f9640a00000 0x00007f9640ddf000 Yes /home/pds/.cache/debuginfod_client/c1ce8a211990184f5d7fe77d3b94ad0b64c85ec2/executable
0x00007f9640600000 0x00007f96409b8000 Yes /home/pds/.cache/debuginfod_client/b86ba1ea98524d1de7cd46a8f54f65633e280eeb/executable
0x00007f963e800000 0x00007f9640550000 Yes (*) /home/pds/.cache/debuginfod_client/fab6d29d039209ed2ee8bae1511c1d436a145cbd/executable
0x00007f9640e3f000 0x00007f9640e49000 Yes (*) /home/pds/.cache/debuginfod_client/5244013d53cae3a5dc074be62e8fdf8ae6bc4efa/executable
0x00007f9640e3a000 0x00007f9640e3f000 Yes (*) /home/pds/.cache/debuginfod_client/3956610e51d2f93ce7eacd9c3378f0dcd0600c46/executable
0x00007f963e725000 0x00007f963e800000 Yes (*) /home/pds/.cache/debuginfod_client/0f68df2ecc3bf901984fb285219026d67356bc58/executable
0x00007f9640e33000 0x00007f9640e38000 Yes (*) /home/pds/.cache/debuginfod_client/948b8cd7e0fb7551a2621b33b2964fc54a0c87c8/executable
0x00007f963e400000 0x00007f963e608000 Yes (*) /home/pds/.cache/debuginfod_client/b5fa5a9afce174ac5751cad3fcbfacbc10158cfd/executable
0x00007f9640e56000 0x00007f9640e8e000 Yes /home/pds/.cache/debuginfod_client/d8fc7cbd7ef0b72e5f077107a4181e76f4f5c88f/executable
No /lib64/libgcc_s.so.1
(*): Shared library is missing debugging information.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
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
0 siblings, 2 replies; 18+ messages in thread
From: Andrew Burgess via Gdb @ 2026-03-11 9:28 UTC (permalink / raw)
To: psmith; +Cc: gdb
Paul Smith <psmith@gnu.org> writes:
> On Tue, 2026-03-10 at 14:20 +0000, Andrew Burgess wrote:
>> Attached below is a **VERY** rough patch which might get things going
>> for you. This patch applies on gdb-17-branch and includes the
>> previous changes I sent, so you should probably revert them and then
>> try this patch to avoid conflicts.
>
> Wow I did not expect such a quick response! However, your patch works
> for me (I fully grok your admonitions about this being a rough draft).
> I did see odd output related to operator() but maybe it's not odd to
> you :)
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.
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.
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.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
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
1 sibling, 0 replies; 18+ messages in thread
From: Paul Smith via Gdb @ 2026-03-11 14:46 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb
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!
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
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
1 sibling, 1 reply; 18+ messages in thread
From: Paul Smith via Gdb @ 2026-03-12 20:38 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
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
0 siblings, 1 reply; 18+ messages in thread
From: Andrew Burgess via Gdb @ 2026-03-13 13:45 UTC (permalink / raw)
To: psmith; +Cc: gdb
Paul Smith <psmith@gnu.org> writes:
> 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.
I suspect this is a use-after-free bug. Try the patch below and let me
know if this fixes things.
Thanks,
Andrew
---
diff --git i/gdb/linux-tdep.c w/gdb/linux-tdep.c
index 27443f7fb4b..148430d6d0a 100644
--- i/gdb/linux-tdep.c
+++ w/gdb/linux-tdep.c
@@ -1169,6 +1169,9 @@ linux_read_core_file_mappings
/* The start address of each mapping. */
gdb::unordered_set<ULONGEST> mapping_start_addr_set;
+ /* ... */
+ gdb::byte_vector contents;
+
/* It's not required that the NT_FILE note exists, so return silently
if it's not found. Beyond this point though, we'll complain
if problems are found. */
@@ -1185,7 +1188,7 @@ linux_read_core_file_mappings
return;
}
- gdb::byte_vector contents (note_size);
+ contents.resize (note_size);
if (!bfd_get_section_contents (cbfd, section, contents.data (), 0,
note_size))
{
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Does gdb debuginfod download libc etc.?
2026-03-13 13:45 ` Andrew Burgess via Gdb
@ 2026-03-13 15:44 ` Paul Smith via Gdb
0 siblings, 0 replies; 18+ messages in thread
From: Paul Smith via Gdb @ 2026-03-13 15:44 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb
On Fri, 2026-03-13 at 13:45 +0000, Andrew Burgess wrote:
> I suspect this is a use-after-free bug. Try the patch below and let
> me know if this fixes things.
Aha! I was looking for some kind of uninitialized filename pointer but
this patch makes perfect sense.
And, it fixes the problem. Nice!
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2026-03-13 15:45 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-03-07 23:58 Does gdb debuginfod download libc etc.? 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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox