On Wed, 30 Sep 2020 10:44:06 +0200, Jakub Jelinek wrote:
On Wed, Sep 30, 2020 at 10:33:59AM +0200, Jan Kratochvil wrote:
> Because doing it separately like GDB does is a wrong thing for
> edit-compile-debug cycle. When clang (lld for LTO) has all the data incl. IR
> already in memory it can much more faster produce the index for it.
clang definitely doesn't have all the data already in memory, it has just a
single translation unit in memory at a time.
So, such a .debug_names is completely useless, because then you don't have
one index, but hundreds if not thousands of them that all needs to be
queried for the same information.
I said "lld for LTO". In Fedora clang has already enabled LTO and then the
.debug_names is produces during lld linking as one unified index:
String: 0x00000030 "C"
Entry @ 0xad {
Tag: DW_TAG_class_type
DW_IDX_compile_unit: 0x00
DW_IDX_die_offset: 0x00000026
}
String: 0x000004ec "main"
Entry @ 0xeb {
Tag: DW_TAG_subprogram
DW_IDX_compile_unit: 0x01
DW_IDX_die_offset: 0x0000002c
}
It is very mean to spread negative lies about toolchains you have no idea
about and you do not even spend a few seconds to check it yourself.
That is why the index should be added by linkers or post-link tools.
This is how slow GNU Toolchain does that. LLVM has learned from those
mistakes.
And, if LLDB can cope only with clang generated .debug_names and
can't deal
with .debug_names generated by other tools, something is seriously wrong.
LLDB can deal with .debug_names generated by other tools but then LLDB will be
affected by bugs in the other tools. In comparison do you want GDB debugging
GCC-built programs to be affected by bugs in LLVM?
Jan