[Lldb-commits] [PATCH] D72880: Fix a buffer-size bug when the first DW_OP_piece is undefined

Adrian Prantl via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Fri Jan 17 11:21:05 PST 2020


aprantl marked an inline comment as done.
aprantl added inline comments.


================
Comment at: lldb/source/Expression/DWARFExpression.cpp:2077
+          // with the expression result, so the debugger can print missing
+          // members as "<optimized out>" or something.
           ::memset(curr_piece.GetBuffer().GetBytes(), 0, piece_byte_size);
----------------
labath wrote:
> vsk wrote:
> > FTR I'm not really sure this case is allowed by the dwarf standard. Under DW_OP_piece the standard references a "preceding simple location description" -- istm like an error if the stack is empty. My $0.0002 :) 
> I think this is fine -- an "empty location description" (section 2.6.1.1.4 of DWARF4) is a kind of a "simple location description" (sect. 2.6.1.1).
> 
> The part that worries me more is this: "Each simple location description that is a DWARF expression is evaluated independently of any others (as though on its own separate stack, if any).". I think that means we should reset/clear the stack after each DW_OP_piece, but we don't currently do that (we just pop the topmost value). However, I am not sure if this has any impact on valid DWARF expressions (though it can cause us to produce bogus values for invalid ones).
That's cute, so with our current implementation one could write a communicating DWARF expression like:

DW_OP_lit1 DW_OP_dup DW_OP_piece 1 DW_OP_piece 1

Is the second byte supposed to be 1 or undef?

;-)

I agree, we should probably clear the stack.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72880/new/

https://reviews.llvm.org/D72880





More information about the lldb-commits mailing list