Comment # 10 on bug 1203497 from Tom de Vries

(In reply to Richard Biener from comment #9)
> 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".