[PATCH] D56587: Introduce DW_OP_LLVM_convert

Mon Feb 11 11:31:12 PST 2019

probinson added a comment.

In D56587#1391461 <https://reviews.llvm.org/D56587#1391461>, @dblaikie wrote:

> In D56587#1391435 <https://reviews.llvm.org/D56587#1391435>, @aprantl wrote:
>
> > In D56587#1390564 <https://reviews.llvm.org/D56587#1390564>, @dstenb wrote:
> >
> > > How should `DW_OP_convert` be handled when targeting DWARF versions earlier than 5? There is the GNU extension `DW_OP_GNU_convert`, which GDB seems to have had support for since 2011. The operation seems to be the identical to the final version that got into DWARFv5, so LLDB should be able to handle the two variants transparently. Can we emit that GNU extension (under some limitations)?
> >
> >
> > That seems fine for debugger-tuning=gdb (and eventually lldb once we implemented support for it). Is emitting the byzantine shift/mask expression that this review started with in all other cases an option for a reasonably large subset of the uses?
>
>
> If we have something nice for GDB and LLDB, and Paul's OK with one of those for Sony's stuff - then who would we be maintaining this extra code for? I'd be OK saying that backwards/sidewards/unspecified compatibility might not be worth it? If someone comes with a need, it could be resurrected/implemented - and until then, we could emit no location at all, potentially.

IIUC what we have are:

- v5: Everybody is okay with DW_OP_convert.
- v4 GDB: clearly DW_OP_GNU_convert is the way to go.
- v4 Sony: do the complicated thing.
- v4 LLDB: either teach it about DW_OP_GNU_convert or do the complicated thing like Sony.

I didn't see any not-the-complicated-thing proposal for cases that don't/can't/won't know about DW_OP_GNU_convert?

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

https://reviews.llvm.org/D56587