[PATCH] D76878: Implement new DW_OP_LLVM_* operations

[Scott Linder via Phabricator via llvm-commits]

scott.linder added a comment.

In D76878#1964010 <https://reviews.llvm.org/D76878#1964010>, @probinson wrote:

> In D76878#1960563 <https://reviews.llvm.org/D76878#1960563>, @scott.linder wrote:
>
> > Right, I think with so few vendor encodings left there has to be some mechanism for reusing them or opening up the encoding space. Just increasing the vendor extension range will eat into the already dwindling standard encoding space. We also tried really hard to make the entire proposal backwards compatible, and switching to ULEB128 seems like a hard break in compatibility as the 7th bit is already active in `DW_OP_`'s even in the non-user range. Maybe reserving a single `DW_OP_` to say "what follows is a ULEB128 extended-opcode" would be feasible, although it would still have a pretty far reaching impact.
>
>
> That's what DWARF does for line-number program opcodes; opcode 0 indicates an "extended" opcode, with a ULEB guarding the whole thing so it can be skipped by consumers who don't recognize it.  If the expression opcode space is feeling the squeeze (which I can easily imagine, as there are only 32 opcodes in that space) it would seem like a reasonable extension to do the same thing in the DWARF expression space.
>
> For your implementation, you would want to use one of the existing user-range opcodes, but you could define that as introducing the extended-opcode encoding.  Please model it on how line-number extended opcodes work.


I'm still hesitant to include this in the current proposal because it seems out of scope. The augmentation approach satisfies the need to be able to overlap with existing extensions, and is modeled on the notion of augmentation in the CFI. It does this without structural changes that will ripple through every tool interacting with DWARF expressions, which is an important property for us because we are striving to upstream these new ops into a future DWARF standard and delete these temporary ops anyway. I agree that a separate proposal to resolve the issue in a more general way for both standard and user ranges would be a good idea, but it isn't what we are proposing here.

In the context of LLVM as a generator and consumer of these user `DW_OP`s nothing is actually required as the overlapping extensions aren't even supported, and in the context of consumers like GDB the augmentation will be sufficient to differentiate between supported extensions. Even there, I don't think they currently implement the overlapping extensions beyond being able to print them. Would that be sufficient to get this landed in LLVM, with the understanding that these are not intended to be extensions permanently, and that solving the encoding exhaustion issue could still be proposed and implemented another way?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76878