[PATCH] D76878: Implement new DW_OP_LLVM_* operations

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

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.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76878