Due to missing relocation support in libdwarf for powerpc64, handling of dwarf info on unlinked objects was bogus.
Examining raw dwarf data on objects compiled on ppc64 with a modern compiler (in-tree gcc tends to hide the issue, since it only rarely generates relocations in .debug_info and uses DW_FORM_str instead of DW_FORM_strp for everything), you will find that the dwarf data appears corrupt, with repeated references to the compiler version where things like types and function names should appear.
This happens because the 0 offset of .debug_str contains the compiler version, and without applying the relocations, *all* indirect strings in .dwarf_info will end up pointing to it.
This corruption then propogates to the CTF data, as ctfconvert relies on libdwarf to read the dwarf info, for every compiled object (when building a kernel.)
However, if you examine the dwarf data on a compiled executable, it will appear correct, because during final link the relocations get applied and baked in by the linker.
"I can't believe we got this far without it." -- me, initial summary