GDB fails to find source files if package is using Meson to build itself. For example, app-arch/zstd: $ gdb /usr/bin/zstd Reading symbols from /usr/bin/zstd... Reading symbols from /usr/lib/debug//usr/bin/zstd.debug... (gdb) disass /s main Dump of assembler code for function main: ../../programs/zstdcli.c: warning: 832 ../../programs/zstdcli.c: No such file or directory ---- GDB searches paths which look like this: "/usr/src/debug/app-arch/zstd-1.5.6/zstd-1.5.6/build/meson-abi_x86_64.amd64/../../programs/zstdcli.c" = -1 ENOENT (No such file or directory) "/usr/src/debug/app-arch/zstd-1.5.6/zstd-1.5.6/build/meson-abi_x86_64.amd64/../../programs/zstdcli.c" = -1 ENOENT (No such file or directory) "/usr/src/debug/app-arch/zstd-1.5.6/zstd-1.5.6/build/meson-abi_x86_64.amd64/usr/src/debug/app-arch/zstd-1.5.6/zstd-1.5.6/build/meson-abi_x86_64.amd64/../../programs/zstdcli.c" = -1 ENOENT (No such file or directory) "/usr/src/debug/app-arch/zstd-1.5.6/zstd-1.5.6/build/meson-abi_x86_64.amd64/zstdcli.c" = -1 ENOENT (No such file or directory) ---- The above lines are an excerpt from a strace file generated by "strace -o gdb.strace -- gdb /usr/bin/zstd". ---- The app-arch/zstd package has installed the following source file: $ qlist --showdebug zstd | grep zstdcli /usr/src/debug/app-arch/zstd-1.5.6/zstd-1.5.6/programs/zstdcli.c ---- Not sure whether this issue is specific to app-arch/zstd only - or applies to all packages built with Meson and FEATURES="installsources splitdebug". Please check whether this issue is reproducible with other apps/libs which are using Meson. Reproducible: Always
The debugger doesn't collapse this segment: build/meson-abi_x86_64.amd64/../../ It is caused by e.g. <3225d> DW_AT_name : (indirect line string, offset: 0xe3): ../../programs/zstdcli.c <32261> DW_AT_comp_dir : (indirect line string, offset: 0x1e): /usr/src/debug/app-arch/zstd-1.5.6/zstd-1.5.6/build/meson-abi_x86_64.amd64
I don't think it has much of anything to do with the See Also. When using a ${BUILD_DIR} that isn't the same as ${S}, you are prone to getting compiler paths that are temporary artifacts of the layout of ${WORKDIR}, with relative paths based on calculations that aren't available at install time. It doesn't matter whether merge-wait is enabled, you'd need to rewrite both DW_AT_name and DW_AT_comp_dir to resolve abspaths here -- or package up the directories even though they are unused, so that the debugger can resolve them at runtime.
(In reply to Eli Schwartz from comment #2) > I don't think it has much of anything to do with the See Also. "See Also" links are bidirectional. Is it possible to put a link to this bug only in https://bugs.gentoo.org/942760?
Oh, that's a fair point. :)
The directory DW_AT_comp_dir doesn't exist: $ ls /usr/src/debug/app-arch/zstd-1.5.6/zstd-1.5.6/build/meson-abi_x86_64.amd64/../../programs/zstdcli.c /bin/ls: cannot access '/usr/src/debug/app-arch/zstd-1.5.6/zstd-1.5.6/build/meson-abi_x86_64.amd64/../../programs/zstdcli.c': No such file or directory $ ls /usr/src/debug/app-arch/zstd-1.5.6/zstd-1.5.6/ total 13k drwxr-xr-x 3 root root 4.1k Nov 10 16:29 contrib drwxr-xr-x 7 root root 4.1k Nov 10 16:29 lib drwxr-xr-x 2 root root 4.1k Nov 10 16:29 programs ---- I think a good step in fixing this bug would be for DW_AT_comp_dir to point to an existing directory, and after that is done adjust the DW_AT_name entries. It is wrong for Portage to indirectly pass a non-existent directory to GDB (and in general wrong to mention a non-existent directory in any file installed by Portage) and expect GDB to figure out the problem by itself.
That's not really how it works, unfortunately. DW_AT_name and DW_AT_comp_dir are the debuginfo recordings of: DW_AT_name: the filename passed as an argument to the compiler DW_AT_comp_dir: the $PWD when the compiler was executed, usually the eclass variable ${BUILD_DIR} "It should just point to an existing directory" is very simple to say, but a lot harder to do. If you have suggestions for how this should work, it would be great to hear those. My naive initial thought is that portage would need to keepdir each directory and make it exist.
(In reply to Eli Schwartz from comment #6) > My naive initial thought is that portage would need to keepdir each > directory and make it exist. If Portage can read DW_AT_comp_dir directly, then I agree the above solution would work and should be reliable. On the other hand, if only dev-util/debugedit can read DW_AT_comp_dir directly, then Portage would need to be updated to somehow obtain the value of DW_AT_comp_dir.
