https://bugzilla.suse.com/show_bug.cgi?id=1203497
https://bugzilla.suse.com/show_bug.cgi?id=1203497#c10
--- Comment #10 from Tom de Vries
I don't quite understand why gdb cannot handle both CTF and DWARF at the same time
The common use case for ctf is to be used when dwarf is not available, and not to be used when dwarf is available (assuming they contain roughly the same scope of info, but with the dwarf one more detailed than the ctf one), and that idea was also implemented in gdb. To put it more concretely: it's targeted at a distro with optional separate dwarf debug-info. If the dwarf debug-info is installed (or downloaded), use it. If not, use the ctf (also tools may opt to ignore the dwarf and read ctf out of speed/memory concerns, but that's more the domain of non-debugger readers). I rfc-ed a patch ( https://sourceware.org/pipermail/gdb-patches/2022-September/192044.html ) that introduces a command to control symbol reading order, where the default is reflected by: ... (gdb) maint set symbol-read-order mdebug+stabs+dwarf2/ctf ... meaning don't read ctf if dwarf2 is present. Then, by using ... (gdb) maint set symbol-read-order ctf ... I can make the gdb test-cases pass (because there's no useful info in the dwarf, so ignoring it is fine). Reading both ctf and dwarf2 is supported by: ... (gdb) maint set symbol-read-order dwarf2+ctf ... or the opposite order, which seems to work ok for disjunct scope, in the test-case I added. But I think I'm the first to try this out, so there may be problems lurking. I have no idea what happens for overlapping scope. This used to be predictable when dwarf got translated into partial symbol tables, the same as the other formats, but that's not the case anymore in gdb-13, due to the the speed improvement introduced the "cooked index". -- You are receiving this mail because: You are on the CC list for the bug.