================
@@ -370,6 +370,31 @@ bool SymbolContext::GetAddressRange(uint32_t scope,
uint32_t range_idx,
return false;
}
+Address SymbolContext::GetAddress(uint32_t scope,
+ bool use_inline_block_range) const {
+ if ((scope & eSymbolContextLineEntry) && line_entry.IsValid())
+ return line_entry.range.GetBaseAddress();
+
+ if (scope & eSymbolContextBlock) {
+ Block *block_to_use = (block && use_inline_block_range)
+ ? block->GetContainingInlinedBlock()
+ : block;
+ if (block_to_use) {
+ Address addr;
+ block_to_use->GetStartAddress(addr);
+ return addr;
+ }
+ }
----------------
labath wrote:
The part that bothers me is that the "address of a block" isn't a very well
defined concept. For functions/symbols, I think it's clear -- is the address
you jump to when you want to "call" the functions. Line entries are contiguous
so it sort of makes sense to say that its address is the beginning of that
range, though I don't think that guarantees that address will ever be executed
(*). For blocks, it's even messier, because even "regular" compiler
optimizations (no propellers or bolts) can make the block discontiguous.
Block::GetStartAddress returns the lowest address in the block, so the result
maybe be not just be not executed, it may be in a completely different part of
the function. It's not wrong, if that's what you expect. I think it's just..
confusing. But not supporting the flag would be confusing as well, so... :shrug:
(*) I don't know if you can get a compiler to emit something like this, but I
don't think it would be wrong to describe `insn1` and `insn2` in the following
snippet with the same line entry:
```
jcc 2f
insn1
2: insn2
```
(insn1 is executed only if some condition is met and the two happen to be on
the same line. Let's assume we're not using column numbers here)
https://github.com/llvm/llvm-project/pull/123340
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
