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
