clayborg added a comment.

Sounds like a win then, as long as we don't get slower I am fine with this. I 
was guessing that line tables might be faster because it is generally very 
compressed and compact compared to debug info, but thanks for verifying.

Might be worth checking the memory consumption of LLDB quickly too with 
DW_AT_ranges compiled out and just make sure we don't take up too much extra 
memory.

We aren't doing anything to unload these line tables like we do with DIEs are 
we? It might make sense to pares the line tables and then throw them away if 
they were not already parsed?  With the DIEs we were throwing them away if they 
weren't already parsed to keep memory consumption down, so might be worth 
throwing the line tables away after running this if we are now going to rely on 
it.

One other thing to verify we want to go this route is to re-enable the old DIE 
parsing for high/low PCs, but put the results in a separate address ranges 
class. After we parse the line tables, verify that all ranges we found in the 
DIEs are in the line tables? It would not be great if we were going to start 
missing some functions if a function doesn't have a line table? Not sure if/how 
this would happen, but you never know.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D78489/new/

https://reviews.llvm.org/D78489



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

Reply via email to