| Issue |
204293
|
| Summary |
[lldb] lldb resumes DWARF _expression_ decoding from DW_OP_bra / DW_OP_skip targets inside another operation's operand bytes
|
| Labels |
|
| Assignees |
|
| Reporter |
firmiana402
|
While reviewing DWARF _expression_ control flow, I noticed that LLDB appears to treat a `DW_OP_bra` or `DW_OP_skip` destination as any in-range byte offset within the current _expression_.
One compact example is:
```text
DW_OP_skip +1
DW_OP_const1u 0x37
DW_OP_stack_value
```
The decoded target lands on the payload byte `0x37` of `DW_OP_const1u`, not on the first byte of a separately encoded operation.
If the destination lands inside the operand bytes of a later operation, LLDB continues decoding from that byte as if it were a fresh opcode.
I realize the [DWARF v5](https://dwarfstd.org/doc/DWARF5.pdf) text defines these branch offsets in bytes, and I have not found an explicit sentence saying that the destination must be the first byte of an operation. This appears to be a standards-interpretation question rather than a clear-cut conformance bug.
Still, the behavior seems surprising. DWARF describes an _expression_ as a stream/sequence of operations, where each operation consists of an opcode followed by zero or more operand bytes. Against that model, resuming execution in the middle of another operation's encoded operands seems at least worth validating explicitly or clarifying.
More concretely, DWARF v5 Section 2.5 presents a DWARF _expression_ as an encoded stream of operations whose operand layout is determined by each opcode, and DWARF v5 Section 7.7.1 presents the _expression_ bytes as a sequence of operations, each with a 1-byte opcode followed by its additional data bytes. Those do not explicitly forbid an interior branch target, but they do describe the _expression_ as an already structured sequence of operations. That is why decoding from the middle of another operation's operand bytes stood out.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
