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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
