[PATCH] D75326: [entry values] X86: Describe effects of MOV{8,16}ri (PR45053)

Mon Mar 16 16:24:35 PDT 2020

vsk added a comment.

@djtodoro thanks for landing a workaround!

In D75326#1912624 <https://reviews.llvm.org/D75326#1912624>, @dstenb wrote:

> In D75326#1904157 <https://reviews.llvm.org/D75326#1904157>, @vsk wrote:
>
> > Sorry for the delay here.
> >
> > @dstenb wrote:
> >
> > > When I print that in GDB 8.2.1, 0x5566 is printed instead of 0x11225566 which is the actual parameter value:
> >
> > Yeah, this sounds like a debugger bug to me. The debugger should print something that indicates that the upper bits of "param" are unknown. Although, to be fair, lldb has the same bug (or it might be worse, and print out "param" as 0x00005566 -- it doesn't track the bits of a variable that are uncovered by pieces).
> >
> > > The DW_OP_entry_value operation at the callee expects a value to be pushed to the DWARF stack when evaluating the DW_AT_call_value at the caller. How should/would that work with composite descriptions?
> >
> > Well, in lldb at least, I think the idea is that while OP_piece doesn't push anything to the stack, it changes the debugger's notion of which bits in the evaluated result are "valid". So one way this could work is: the result of evaluating the DW_AT_call_value is pushed onto the stack when evaluating DW_OP_entry_value (and if it's e.g. a 2-byte piece, so be it).
> >
> > All of which sounds a little iffy to me for what appears to be a pretty uncommon case (fwiw I was able to build all of clang & LNT for x86 without hitting this).
>
>
> Sorry for the late response!
>
> Would that only work when you a have a single `DW_OP_piece`? Or would it be possible to have multiple composition operations in a `DW_AT_call_value`? What would happen in the latter case?

That's an interesting question. On one hand, it doesn't seem like there should be anything special about having multiple composition operations. OTOH, if the debugger's representation of an evaluated expression ("Value" in lldb parlance) doesn't track which bits are known, the debugger might evaluate an entry value incorrectly if it encounters a DW_AT_call_value like "[...; DW_OP_piece 4; ..; DW_OP_piece 2]".

> I'm sorry if I'm a bit persistent here. Please don't let me stand in the way if this can be made to work with LLDB, and the GDB developers can be convinced that them ignoring `DW_OP_piece` is a bug. I'm personally just not entirely convinced that that is valid DWARF.

No worries, I think this is great feedback. I think we've just touched on a tricky part of the standard. Do you still have the time to start a discussion about this on the dwarf mailing list?

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

https://reviews.llvm.org/D75326