On Wed, 30 Sep 2020 02:11:34 +0200, Neal Gompa wrote:
Why don't you add an lldb-add-index tool to generate LLVM indexes
for
LLDB?
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.
With gdb-add-index it is questionable whether to use it or not for
edit-compile-debug cycles. If you run debugger just once for the compiled
program it is slower to generate + use the index just once than to run the
debugger without any index.
The index production performance does not matter much for rpmbuild as that
takes a long time anyway. But keeping the end-user edit-compile-debug cycle
unified with rpm build process makes the code path more tested and more
simple.
Then we just invoke it as part of the buildroot policy setup and
get both GDB and LLDB indexes? This proposal seems to be particularly
destructive to GDB users to favor LLDB.
I do not see how this affects GDB. This Change expects clang will produce
.debug_names and rpmbuild will call gdb-add-index which will add .gdb_index.
Then there will be both indexes for both debuggers.
That is not great longterm but in some time GDB should fix its .debug_names
consumer to be compatible with the DWARF-5 standard and then Fedora can drop
.gdb_index completely.
(TBH I am not completely sure that LLDB conforms to the DWARF-5 standard as
the standard is not too descriptive of the format. But LLDB is at least more
.debug_names standard compliant despite "more compliant" may sound funny.)
I personally don't use LLDB for *anything*, since I think
it's not a
particularly good debugger right now,
Please do not be offensive to the other toolchain. I also must not be so it is
unfair. I could argue with numbers but I won't.
performance of debugging clang-built things with GDB degraded.
This is not intended/expected.
Jan