[Lldb-commits] [lldb] [lldb] Handle improperly nested blocks differently (PR #117725)

[Pavel Labath via lldb-commits]

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