[PATCH] D76878: Implement new DW_OP_LLVM_* operations

[Scott Linder via Phabricator via llvm-commits]

scott.linder added a comment.

In D76878#1958975 <https://reviews.llvm.org/D76878#1958975>, @jhenderson wrote:

> In D76878#1958215 <https://reviews.llvm.org/D76878#1958215>, @scott.linder wrote:
>
> > In the mean time, I would like to ask if any of the reviewers have thoughts on how to reconcile the need for more new `DW_OP_` extensions than there is encoding space for. Currently we are proposing adding a `DW_AT_augmentation` which could be applied to `DW_TAG_compile_unit` which will essentially allow for us to say "this compile unit uses extension X", and as part of our definition of the extension we could indicate that we are using certain encodings that may already be in use elsewhere. Essentially this would be a way for extension vendors to multiplex over the same limited encoding space. I imagine we would carry this augmentation string in the DICompileUnit metadata.
>
>
> This is very similar in concept to what ELF does with SHT_NOTE sections - individual elements in this section use a vendor field, which is a string, and then also have types, but the types are specific to each vendor, thus e.g. GNU type 1 and LLVM type 1 could mean two completely different things. I believe consumers are intended to ignore unknown vendors.


Yes, I think our proposal is in the same vein, although it is complicated slightly by a desire to support multiple extensions being present at the same time. For example, AMDGPU wants to say that we need these new operations while still supporting GNU and LLVM extensions like `GNU_push_tls_address` when we know the consumer prefers them.

> Whatever approach is taken will presumably need adopting in the next DWARF standard. An obvious straightforward alternative would be to increase the range available for DW_OP_ vendor extensions. It might be worth at the same time considering changing to using ULEB128s for DW_OP encodings.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76878