labath wrote: > Will this patch cause us to be able to have a `DW_TAG_subprogram` whose range > is `[0x1000-0x2000)` and then have a `DW_AT_lexical_block` whose range > doesn't exist within the `DW_TAG_subprogram` range and we will add it to the > `DW_TAG_subprogram`? I worry because LTO and other passes might end up > setting the address of a contained block to zero or -1 (tombstone). We don't > want those added to the parent range unless the address is in the > `DW_TAG_subprogram` range.
I can answer that very simply and confidently: No. :) This patch strictly reduces the number of ranges on blocks, and it has nothing to do with filtering tombstone ranges, which happens [here](https://github.com/llvm/llvm-project/blob/f590843616d22338ca4bfd1c8623a5dc7c76b6ec/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp#L920) (for functions, we do filtering for blocks as well, but we do it slightly differently). I think it actually does what you want, or at least moves us into that direction. Without this patch, if we ever ran into a situation where the a block has a tombstoned range but the parent function doesn't have it (perhaps because it was filtered out by the code I linked to), then we would end up (re)adding the tombstoned range to the parent function. With this patch, the range will not get added (and we will produce an error/warning notifying us about that situation). If we see that warning firing, then it may mean we need to do a better job at filtering the block ranges. https://github.com/llvm/llvm-project/pull/117725 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
