dblaikie added a comment.
Herald added a subscriber: teemperor.

In https://reviews.llvm.org/D51208#1212320, @labath wrote:

> As far as the strict intention of this test goes, the change is fine, as it 
> is meant to check that the accelerator tables get used *when* they are 
> generated. How do you achieve them being generated is not important.
>
> However, I am not sure now under what circumstances will the accelerator 
> tables be emitted in the first place. David, does this mean that we will now 
> not emit .debug-names even if one specifies `-glldb`? Was that intentional?


Not especially intentional - but I clearly didn't give it quite enough thought. 
Mostly I was modelling the behavior of GCC (no pubnames by default - you can 
opt-in to them (& split-dwarf opts in by default, but one thing GCC didn't do 
was allow them to be turned off again - which is what I wanted)).

As for the default behavior for DWARFv5 - have you run much in the way of 
performance numbers on how much debug_names speeds things up? From what I could 
see with a gdb-index (sort of like debug_names - but linker generated, so it's 
a single table for the whole program) it didn't seem to take GDB long to 
parse/build up its own index compared to using the one in the file. So it 
seemed to me like the extra link time, object size, etc, wasn't worth it in the 
normal case. The really bad case for me is split-DWARF (worse with a 
distributed filesystem) - where the debugger has to read all the .dwo files & 
might have a high latency filesystem for each file it reads... super slow. But 
if the debug info was either in the executable (not split) or in a DWP (split 
then packaged), it seemed pretty brief.

But if LLDB has different performance characteristics, or the default should be 
different for other reasons - I'm fine with that. I think I left it on for 
Apple so as not to mess with their stuff because of the MachO/dsym sort of 
thing that's a bit different from the environments I'm looking at.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D51208



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to