Summary: gdb cannot move up a directory that does not exist in the source tree when looking for a source file. Steps to reproduce on Ubuntu 22.04: 1. { DEBUGINFOD_URLS='https://debuginfod.ubuntu.com' && export DEBUGINFOD_URLS; } 2. set debuginfod enabled on 3. attach to a running yelp 3.1. debuginfod will download debuginfo and refuse to download source files 4. { cd "${HOME}/.cache/debuginfod_client/a4f415af56b06f1f38d5a0339dd9828ff136b115/" && apt source libc6 && cd ../c74e800dfd5f72649d673b44292f4a817e45150b/ && apt source libglib2.0-0; } 5. dir ${HOME}/.cache/debuginfod_client/a4f415af56b06f1f38d5a0339dd9828ff136b115/glibc-2.35 6. dir ${HOME}/.cache/debuginfod_client/c74e800dfd5f72649d673b44292f4a817e45150b/glib2.0-2.72.4 7. detach and attach 8. up Expected result: 4518 ret = (*poll_func) (fds, n_fds, timeout); Actual result: Continuing without source file ./debian/build/deb/../../../glib/gmain.c. 4518 ../../../glib/gmain.c: No such file. Work-around: { install -d "${HOME}/.cache/debuginfod_client/c74e800dfd5f72649d673b44292f4a817e45150b/glib2.0-2.72.4/debian/build/deb"; }
Some baby investigation with ubuntu 22.04 binaries, taking /bin/ls as an example: eu-readelf -w `debuginfod-find debuginfo /bin/ls`: DWARF section [30] '.debug_info' at offset 0x438: [Offset] Compilation unit at offset 0: Version: 5, Abbreviation section offset: 4084, Address size: 8, Offset size: 4 Unit type: partial (3) [ c] partial_unit abbrev: 50 stmt_list (sec_offset) 0 comp_dir (line_strp) "." Compilation unit at offset 3348: Version: 5, Abbreviation section offset: 0, Address size: 8, Offset size: 4 Unit type: compile (1) [ d20] compile_unit abbrev: 43 producer (GNU_strp_alt) "GNU GIMPLE 11.2.0 -mtune=generic -march=x86-64 -g -g -O2 -O2 -fno-openmp -fno-openacc -fPIC -fcf-protection=full -fstack-protector-strong -ffat-lto-objects -fltrans" language (data1) C11 (29) name (line_strp) "<artificial>" comp_dir (line_strp) "." i.e., AT_comp_dir = "." MJW advises this implicates https://dwarfstd.org/issues/210628.1.html , wherein it is acknowledged that absolute paths are expected, and offers semantics to DWARF6 for special cases. Those special cases would not help at all in the debuginfod-supplied cases, where the file names in the client cache have no relationship to the build system's file tree or the installed location of the binary. So the question is why are these binaries arriving with ".", seeing that they were produced by GCC.
In particular the latest draft (note draft! can still change!) https://snapshots.sourceware.org/dwarfstd/dwarf-spec/latest/ says: --- DRAFT --- A DW_AT_comp_dir attribute whose value is a null-terminated string containing the current working directory of the compilation command that produced this compilation unit in whatever form makes sense for the host system. If a relative path is used in DW_AT_comp_dir, it will be relative to the location of the linked image containing the DW_AT_comp_dir entry. In some cases a producer may allow the user to specify a relative path for DW_AT_comp_dir. There are a few cases in which this is useful, but in general using a relative path for DW_AT_comp_dir is discouraged as it will not work well in many cases including the following: different relative paths are used within the same build; the build system creates multiple linked images in different directories; the final linked image is moved before being debugged; .o files that need to be debugged directly. --- DRAFT --- So that seems to imply that you really shouldn't use relative paths (like "."), unless you can make sure that when the image or source files are moved (or the DWARF is put into a separate .debug file) like when doing make install, all the relative are updated/resolved/rewritten.
Closing this as NOTABUG. The query fails due to the presence of a relative pathname in the debuginfo (./debian/build/deb/...). Debuginfod can only perform source file queries on absolute pathnames.