Implement DW_{OP,AT}_LLVM_* for Heterogeneous Debugging

[scott.linder]

Summary

The extensions are gaurded by the flag SupportsHeterogeneousDebuggingExtensions
which is disabled by default, except for AMDGPU.

Though they are several extensions, the encodings are chosen such that they don't
occupy the entire available space and doesn't have collisions. If at all we land
into encoding collisions due to future extensions, the ambiguity can be resolved
by using the proposed new augmentation attribute on the compilation unit and in
unwind information CIEs for any target which wishes to use the operations
defined by the extensions.

[jhenderson]

I've added a few reviewers who are probably better placed to review things from the DWARF/DW_OP perspective than me.

[djtodoro]

Please add the debug-info project in all the patches.

I don't see a verifier for these operations, please add that.

llvm/include/llvm/BinaryFormat/Dwarf.def

878

Should the Vendor be AMD (or AMDGPU) instead of LLVM? Or this is only LLVM related.

What about other tools, such as GDB, do they have the support for this?

[dstenb]

llvm/test/tools/llvm-dwarfdump/X86/amdgpu_proposal.s

26–27 ↗

(On Diff #252938)

In which ways does this differ from DW_CFA_undefined reg0?

[aprantl]

llvm/include/llvm/BinaryFormat/Dwarf.def

878

According to libdwarf these numbers are already taken by HP extensions. I don't know how much this practically matters, but it would be good if we imported all the various vendor extension ranges from libdwarf and binutils...

878

Should the Vendor be AMD (or AMDGPU) instead of LLVM? Or this is only LLVM related.

If the extensions are only useful for AMD hardware then that would be appropriate. If they are generally useful the LLVM vendor might make more sense.

[scott.linder]

Thank you for the review, and sorry for neglecting to include any context. The proposal which defines these new operations is at https://llvm.org/docs/AMDGPUUsage.html#dwarf. @t-tye is working on formatting the proposal to be sent to upstream DWARF as an RFC, and I am working to land these patches as an initial implementation.

llvm/include/llvm/BinaryFormat/Dwarf.def

878

These extensions are generally useful, and we are working on implementing them in GDB (currently in an open-source fork rather than directly upstream, although our intention is to upstream as feasible) in parallel with implementing them in LLVM so we have an initial implementation to prove the concept.

The DW_OP_ user encodings have become pretty cramped, as operations are added but never removed, even when they are eventually upstreamed into a version of DWARF. I know that e.g. AArch64 has elected to reserve one encoding to represent a "family" of instructions, where the first operand is the true "AArch64 opcode", but that comes with a lot of infrastructure work and either means we have to break the invariant that operations have a fixed number of opcodes or we have to waste a lot of space in the final encoding with un-used operands.

Our current intention is to instead implement the DW_AT_LLVM_augmentation described at https://llvm.org/docs/AMDGPUUsage.html#debugging-information-entry-attributes as a temporary way to select which of the overloaded versions of these user opcodes should be used for a given DIE.

llvm/test/tools/llvm-dwarfdump/X86/amdgpu_proposal.s

26–27 ↗

(On Diff #252938)

It is not a CFA-only rule, it is just a new dwarf expression operation. DW_OP_LLVM_undefined pushes an "undefined location description" on the stack, which is a new concept that was needed in order to generalize the DWARF stack to support operating on location descriptions. It is a way to explicitly capture the existing rule where two adjacent DW_OP_piece-like operations result in some undefined bits in the final composite location description. @t-tye can probably do a better job describing how it relates to the undefined CFA rule in the new proposal; I think in this case the two forms are equivalent, as they will both result in the unwound register location description being an undefined location description.

I am only using .cfi_escape here as a hacky way to generate some DWARF expressions in a way that dwarfdump will parse, i.e. none of these expressions have to be reasonable things one would want to emit.

[scott.linder]

In D76878#1945912, @djtodoro wrote:

Please add the debug-info project in all the patches.

I don't see a verifier for these operations, please add that.

I'm not sure what verifier you're referring to; is this a part of CodeGen or DebugInfo?

[djtodoro]

In D76878#1946934, @scott.linder wrote:

In D76878#1945912, @djtodoro wrote:

Please add the debug-info project in all the patches.

I don't see a verifier for these operations, please add that.

I'm not sure what verifier you're referring to; is this a part of CodeGen or DebugInfo?

The Debug Info.
Depending on the intention of using this we should add verifiers for the levels of representation. E.g. if we use it on LLVM IR, we should add a verifier in lib/IR/Verifier. The verifier for operation from the final DWARF context is stored within lib/DebugInfo/DWARF/DWARFVerifier.

Anyhow, I think that having an RFC would make this easier for the review. :)

[scott.linder]

In D76878#1949376, @djtodoro wrote:

In D76878#1946934, @scott.linder wrote:

In D76878#1945912, @djtodoro wrote:

Please add the debug-info project in all the patches.

I don't see a verifier for these operations, please add that.

I'm not sure what verifier you're referring to; is this a part of CodeGen or DebugInfo?

The Debug Info.
Depending on the intention of using this we should add verifiers for the levels of representation. E.g. if we use it on LLVM IR, we should add a verifier in lib/IR/Verifier. The verifier for operation from the final DWARF context is stored within lib/DebugInfo/DWARF/DWARFVerifier.

Anyhow, I think that having an RFC would make this easier for the review. :)

The diff at https://reviews.llvm.org/D70523 served as the initial RFC, and @t-tye is still working diligently to update it and reformat it in preparation for presenting it to DWARF proper. In the mean time any review of that that section of AMDGPUUsage.rst is welcome. We hope to be able to implement as much as feasible in a compiler (LLVM) and debugger (GDB) in parallel with working to propose it to DWARF as a way to prove an implementation is feasible.

I will look into extending DWARFVerifier further, but this patch does not include any more fundamental changes that would be needed to implement the entire proposal, it implements just enough of it to emit unwind information needed for AMDGPU. I was hoping to review and land this series of patches before starting the remaining work which will involve changes in IR/MIR/DebugInfo.

[probinson]

The diff at https://reviews.llvm.org/D70523 served as the initial RFC

That's not what we mean by an RFC; what we mean is a narrative writeup that is then posted to the appropriate -dev list (llvm-dev in this case).
Reviews do not get the visibility you want for a significant change or enhancement to how we use things like DWARF. I can't say I noticed that previous review.

Given you've already committed the writeup in the previous review, the post to llvm-dev could be short with a pointer to that doc. But that way at least more of the people who care about DWARF will be aware of it.

[scott.linder]

In D76878#1950365, @probinson wrote:

The diff at https://reviews.llvm.org/D70523 served as the initial RFC

That's not what we mean by an RFC; what we mean is a narrative writeup that is then posted to the appropriate -dev list (llvm-dev in this case).
Reviews do not get the visibility you want for a significant change or enhancement to how we use things like DWARF. I can't say I noticed that previous review.

Given you've already committed the writeup in the previous review, the post to llvm-dev could be short with a pointer to that doc. But that way at least more of the people who care about DWARF will be aware of it.

That makes sense, I'll post a true RFC to the lists soon and we can go from there. I talked with Tony and he has nearly finished updating the proposal to be in the style of a typical DWARF issue, so I am going to hold off on posting to the list until that is done as it will change the structure of the document quite a bit.

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.

[jhenderson]

In 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.

[scott.linder]

In D76878#1958975, @jhenderson wrote:

In 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.

[probinson]

In 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.

[scott.linder]

In D76878#1964010, @probinson wrote:

In 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_OPs 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?

[scott.linder]

Add appropriate augmentation strings to CU and CIE

[scott.linder]

Update title and summary.

[scott.linder]

Rebase and move tests to .debug_info as some new operations are not legal in
.debug_frame.

[RamNalamothu]

Rebase

[RamNalamothu]

Rebase

[RamNalamothu]

Rebase onto LLVM master

[RamNalamothu]

Rebase onto LLVM master

[scott.linder]

llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUMCAsmInfo.cpp

45

I think I missed actually adding a test for this, i.e. that we do emit the augmentation string for AMDGPU.

[RamNalamothu]

Rebase and ping.

[clayborg]

llvm/lib/MC/MCDwarf.cpp

1605

Should we use a single character here? If we don't, unwinders might end up parsing each character individually and that might make unwinders fail as they parse each character. Or does the unwind spec state that everything between square brackets is a single entry? This seems dangerous unless the spec has some rule like this.

[RamNalamothu]

Rebase on to the ToT.

Taking a relook at the vendor extension range, there are enough non-conflicting encodings available for the DWARF operators being proposed here and also leaves few more encodings available for other future extensions LLVM might see.

Does this look good now to go in?

[RamNalamothu]

Rebase and ping.

[RamNalamothu]

Rebase onto ToT.

[RamNalamothu]

Could someone review/comment/approve this revision?

This revision is under review for the last two years. I would appreciate any feedback which helps to make progress on this.

[djtodoro]

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1056

no need for the curly brackets here

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h

750

I'd say that the link was mentioned too many times.

llvm/lib/MC/MCDwarf.cpp

1605

@RamNalamothu have you taken a look into this?

[RamNalamothu]

Address feedback.

[RamNalamothu]

@djtodoro thanks for the quick response

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp

1056

Done.

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h

750

I got rid of the redundant ones. And the rest, unless they are big annoyance, I feel they provide ready access and inform what is being supported.

llvm/lib/MC/MCDwarf.cpp

1605

The thinking behind the multi-character versioning is:

• we should be able to distinguish multiple versions from multiple vendors because
  1. some encoding spaces, e.g. DW_OP_*, are too short and the available encodings are quickly occupied leading to collisions
  2. many historic encodings are not being removed from the code base even when they are not being generated from the compiler
• it's better to follow a standard versioning such as https://semver.org

I don't think all of the above could be addressed using a single character versioning in a meaningful clean manner, if at all it can be done. And the spec can enforce what is needed from all the interfacing tools.

[RamNalamothu]

Ping

[RamNalamothu]

Ping.

[RamNalamothu]

Ping

[RamNalamothu]

Ping.

[djtodoro]

LGTM from my side.

[RamNalamothu]

Thank you very much @djtodoro.

Since many people have commented on this revision in the past, I would wait for few days before landing the changes.

[dblaikie]

@jmorse @aprantl wouldn't mind if one of you could sign off on this, as folks with more context for the location expression side of DWARF than I have these days.

[RamNalamothu]

Thank you @aprantl.

[scott.linder]

Abandoned in favor of D147279 which avoids using most/all of the remaining user opcode

llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst

 .. table:: DWARF Operation Encodings
    :name: amdgpu-dwarf-operation-encodings-table
 
    ================================== ===== ======== ===============================
    Operation                          Code  Number   Notes
                                             of
                                             Operands
    ================================== ===== ======== ===============================
-   DW_OP_LLVM_form_aspace_address     0xe1     0
-   DW_OP_LLVM_push_lane               0xe2     0
-   DW_OP_LLVM_offset                  0xe3     0
-   DW_OP_LLVM_offset_uconst           0xe4     1     ULEB128 byte displacement
-   DW_OP_LLVM_bit_offset              0xe5     0
-   DW_OP_LLVM_call_frame_entry_reg    0xe6     1     ULEB128 register number
-   DW_OP_LLVM_undefined               0xe7     0
-   DW_OP_LLVM_aspace_bregx            0xe8     2     ULEB128 register number,
+   DW_OP_LLVM_form_aspace_address     0xe9     0
+   DW_OP_LLVM_push_lane               0xea     0
+   DW_OP_LLVM_offset                  0xeb     0
+   DW_OP_LLVM_offset_uconst           0xec     1     ULEB128 byte displacement
+   DW_OP_LLVM_bit_offset              0xf4     0
+   DW_OP_LLVM_call_frame_entry_reg    0xf5     1     ULEB128 register number
+   DW_OP_LLVM_undefined               0xf6     0
+   DW_OP_LLVM_aspace_bregx            0xf7     2     ULEB128 register number,
                                                      ULEB128 byte displacement
-   DW_OP_LLVM_aspace_implicit_pointer 0xe9     2     4-byte or 8-byte offset of DIE,
+   DW_OP_LLVM_aspace_implicit_pointer 0xf9     2     4-byte or 8-byte offset of DIE,
                                                      SLEB128 byte displacement
-   DW_OP_LLVM_piece_end               0xea     0
-   DW_OP_LLVM_extend                  0xeb     2     ULEB128 bit size,
+   DW_OP_LLVM_piece_end               0xfa     0
+   DW_OP_LLVM_extend                  0xfd     2     ULEB128 bit size,
                                                      ULEB128 count
-   DW_OP_LLVM_select_bit_piece        0xec     2     ULEB128 bit size,
+   DW_OP_LLVM_select_bit_piece        0xfe     2     ULEB128 bit size,
                                                      ULEB128 count
    DW_OP_LLVM_push_iteration          TBA      0
    DW_OP_LLVM_overlay                 TBA      0
    DW_OP_LLVM_bit_overlay             TBA      0
    ================================== ===== ======== ===============================
 
 A.7.7.3 Location List Expressions
 +++++++++++++++++++++++++++++++++

llvm/docs/AMDGPUUsage.rst

 ``DW_AT_LLVM_augmentation``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 For AMDGPU, the ``DW_AT_LLVM_augmentation`` attribute of a compilation unit
 debugger information entry has the following value for the augmentation string:
 
 ::
 
-  [amdgpu:v0.0]
+  [amdgpu:v0.1]
 
 The "vX.Y" specifies the major X and minor Y version number of the AMDGPU
 extensions used in the DWARF of the compilation unit. The version number
 conforms to [SEMVER]_.
 
 Call Frame Information
 ----------------------
 
 DWARF Call Frame Information (CFI) describes how a consumer can virtually
 *unwind* call frames in a running process or core dump. See DWARF Version 5
 section 6.4 and :ref:`amdgpu-dwarf-call-frame-information`.
 
 For AMDGPU, the Common Information Entry (CIE) fields have the following values:
 
 1.  ``augmentation`` string contains the following null-terminated UTF-8 string:
 
     ::
 
-      [amd:v0.0]
+      [amd:v0.1]
 
     The ``vX.Y`` specifies the major X and minor Y version number of the AMDGPU
     extensions used in this CIE or to the FDEs that use it. The version number
     conforms to [SEMVER]_.
 
 2.  ``address_size`` for the ``Global`` address space is defined in
     :ref:`amdgpu-dwarf-address-space-identifier`.
 
``augmentation_string_size`` (uword)
   multiple of 4.
 
 ``augmentation_string`` (sequence of UTF-8 characters)
 
   Contains the following UTF-8 string null padded to a multiple of 4 bytes:
 
   ::
 
-    [amdgpu:v0.0]
+    [amdgpu:v0.1]
 
   The "vX.Y" specifies the major X and minor Y version number of the AMDGPU
   extensions used in the DWARF of this index. The version number conforms to
   [SEMVER]_.
 
   .. note::
 
     This is different to the DWARF Version 5 definition that requires the first

llvm/include/llvm/BinaryFormat/Dwarf.def

 HANDLE_DW_AT(0x3b31, BORLAND_closure, 0, BORLAND)
 // LLVM project extensions.
 HANDLE_DW_AT(0x3e00, LLVM_include_path, 0, LLVM)
 HANDLE_DW_AT(0x3e01, LLVM_config_macros, 0, LLVM)
 HANDLE_DW_AT(0x3e02, LLVM_sysroot, 0, LLVM)
 HANDLE_DW_AT(0x3e03, LLVM_tag_offset, 0, LLVM)
 // The missing numbers here are reserved for ptrauth support.
 HANDLE_DW_AT(0x3e07, LLVM_apinotes, 0, APPLE)
+// Heterogeneous Debugging Extensions defined at
+// https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html.
+HANDLE_DW_AT(0x3e08, LLVM_active_lane, 0, LLVM)
+HANDLE_DW_AT(0x3e09, LLVM_augmentation, 0, LLVM)
+HANDLE_DW_AT(0x3e0a, LLVM_lanes, 0, LLVM)
+HANDLE_DW_AT(0x3e0b, LLVM_lane_pc, 0, LLVM)
+HANDLE_DW_AT(0x3e0c, LLVM_vector_size, 0, LLVM)
 
 // Apple extensions.
 
 HANDLE_DW_AT(0x3fe1, APPLE_optimized, 0, APPLE)
 HANDLE_DW_AT(0x3fe2, APPLE_flags, 0, APPLE)
 HANDLE_DW_AT(0x3fe3, APPLE_isa, 0, APPLE)
 HANDLE_DW_AT(0x3fe4, APPLE_block, 0, APPLE)
 HANDLE_DW_AT(0x3fe5, APPLE_major_runtime_vers, 0, APPLE)

 // Historic and not implemented in LLVM.
 HANDLE_DW_OP(0xf0, APPLE_uninit, 0, APPLE)
 // The GNU entry value extension.
 HANDLE_DW_OP(0xf3, GNU_entry_value, 0, GNU)
 HANDLE_DW_OP(0xf8, PGI_omp_thread_num, 0, PGI)
 // Extensions for Fission proposal.
 HANDLE_DW_OP(0xfb, GNU_addr_index, 0, GNU)
 HANDLE_DW_OP(0xfc, GNU_const_index, 0, GNU)
+// Heterogeneous Debugging Extensions defined at
+// https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html.
+// If we land into any collisions with future vendor extensions, this ambiguity
+// is resolved by ensuring CIE augmentation strings and compilation unit
+// DW_AT_LLVM_augmentation strings include i.e. "[llvm:vX.Y]".
+HANDLE_DW_OP(0xe9, LLVM_form_aspace_address, 0, LLVM)
+HANDLE_DW_OP(0xea, LLVM_push_lane, 0, LLVM)
+HANDLE_DW_OP(0xeb, LLVM_offset, 0, LLVM)
+HANDLE_DW_OP(0xec, LLVM_offset_uconst, 0, LLVM)
+HANDLE_DW_OP(0xf4, LLVM_bit_offset, 0, LLVM)
+HANDLE_DW_OP(0xf5, LLVM_call_frame_entry_reg, 0, LLVM)
+HANDLE_DW_OP(0xf6, LLVM_undefined, 0, LLVM)
+HANDLE_DW_OP(0xf7, LLVM_aspace_bregx, 0, LLVM)
+HANDLE_DW_OP(0xf9, LLVM_aspace_implicit_pointer, 0, LLVM)
+HANDLE_DW_OP(0xfa, LLVM_piece_end, 0, LLVM)
+HANDLE_DW_OP(0xfd, LLVM_extend, 0, LLVM)
+HANDLE_DW_OP(0xfe, LLVM_select_bit_piece, 0, LLVM)
 
 // DWARF languages.
 HANDLE_DW_LANG(0x0001, C89, 0, 2, DWARF)
 HANDLE_DW_LANG(0x0002, C, 0, 2, DWARF)
 HANDLE_DW_LANG(0x0003, Ada83, 1, 2, DWARF)
 HANDLE_DW_LANG(0x0004, C_plus_plus, 0, 2, DWARF)
 HANDLE_DW_LANG(0x0005, Cobol74, 1, 2, DWARF)
 HANDLE_DW_LANG(0x0006, Cobol85, 1, 2, DWARF)

llvm/include/llvm/MC/MCAsmInfo.h

protected:
   /// True if target uses parens to indicate the symbol variant instead of @.
   /// For example, foo(plt) instead of foo@plt.  Defaults to false.
   bool UseParensForSymbolVariant = false;
 
   /// True if the target supports flags in ".loc" directive, false if only
   /// location is allowed.
   bool SupportsExtendedDwarfLocDirective = true;
 
+  /// True if the target supports the extensions defined at
+  /// https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html.
+  /// Defaults to false.
+  bool SupportsHeterogeneousDebuggingExtensions = false;
+
   //===--- Prologue State ----------------------------------------------===//
 
   std::vector<MCCFIInstruction> InitialFrameState;
 
   //===--- Integrated Assembler Information ----------------------------===//
 
   // Generated object files can use all ELF features supported by GNU ld of
   // this binutils version and later. INT_MAX means all features can be used,
public:
   }
 
   bool doDwarfFDESymbolsUseAbsDiff() const { return DwarfFDESymbolsUseAbsDiff; }
   bool useDwarfRegNumForCFI() const { return DwarfRegNumForCFI; }
   bool useParensForSymbolVariant() const { return UseParensForSymbolVariant; }
   bool supportsExtendedDwarfLocDirective() const {
     return SupportsExtendedDwarfLocDirective;
   }
+  bool supportsHeterogeneousDebuggingExtensions() const {
+    return SupportsHeterogeneousDebuggingExtensions;
+  }
 
   bool usesDwarfFileAndLocDirectives() const {
     return UsesDwarfFileAndLocDirectives;
   }
 
   bool needsDwarfSectionSizeInHeader() const {
     return DwarfSectionSizeRequired;
   }

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h

private:
   /// Force the use of DW_AT_ranges even for single-entry range lists.
   MinimizeAddrInV5 MinimizeAddr = MinimizeAddrInV5::Disabled;
 
   /// DWARF5 Experimental Options
   /// @{
   AccelTableKind TheAccelTableKind;
   bool HasAppleExtensionAttributes;
   bool HasSplitDwarf;
+  // Enables extensions defined at
+  // https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html
+  bool HasHeterogeneousExtensionAttributes;
 
   /// Whether to generate the DWARF v5 string offsets table.
   /// It consists of a series of contributions, each preceded by a header.
   /// The pre-DWARF v5 string offsets table for split dwarf is, in contrast,
   /// a monolithic sequence of string offsets.
   bool UseSegmentedStringOffsetsTable;
 
   /// Enable production of call site parameters needed to print the debug entry
public:
 
   /// Returns what kind (if any) of accelerator tables to emit.
   AccelTableKind getAccelTableKind() const { return TheAccelTableKind; }
 
   bool useAppleExtensionAttributes() const {
     return HasAppleExtensionAttributes;
   }
 
+  bool useHeterogeneousExtensionAttributes() const {
+    return HasHeterogeneousExtensionAttributes;
+  }
+
   /// Returns whether or not to change the current debug info for the
   /// split dwarf proposal support.
   bool useSplitDwarf() const { return HasSplitDwarf; }
 
   /// Returns whether to generate a string offsets table with (possibly shared)
   /// contributions from each CU and type unit. This implies the use of
   /// DW_FORM_strx* indirect references with DWARF v5 and beyond. Note that
   /// DW_FORM_GNU_str_index is also an indirect reference, but it is used with

llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp

DwarfDebug::DwarfDebug(AsmPrinter *A)
   if (DwarfInlinedStrings == Default)
     UseInlineStrings = TT.isNVPTX() || tuneForDBX();
   else
     UseInlineStrings = DwarfInlinedStrings == Enable;
 
   UseLocSection = !TT.isNVPTX();
 
   HasAppleExtensionAttributes = tuneForLLDB();
+  HasHeterogeneousExtensionAttributes =
+      Asm->MAI->supportsHeterogeneousDebuggingExtensions();
 
   // Handle split DWARF.
   HasSplitDwarf = !Asm->TM.Options.MCOptions.SplitDwarfFile.empty();
 
   // SCE defaults to linkage names only for abstract subprograms.
   if (DwarfLinkageNames == DefaultLinkageNames)
     UseAllLinkageNames = !tuneForSCE();
   else
if (useAppleExtensionAttributes()) {
     if (!Flags.empty())
       NewCU.addString(Die, dwarf::DW_AT_APPLE_flags, Flags);
 
     if (unsigned RVer = DIUnit->getRuntimeVersion())
       NewCU.addUInt(Die, dwarf::DW_AT_APPLE_major_runtime_vers,
                     dwarf::DW_FORM_data1, RVer);
   }
 
+  if (useHeterogeneousExtensionAttributes())
+    NewCU.addString(Die, dwarf::DW_AT_LLVM_augmentation, "[amdgpu:v0.1]");
+
   if (DIUnit->getDWOId()) {
     // This CU is either a clang module DWO or a skeleton CU.
     NewCU.addUInt(Die, dwarf::DW_AT_GNU_dwo_id, dwarf::DW_FORM_data8,
                   DIUnit->getDWOId());
     if (!DIUnit->getSplitDebugFilename().empty()) {
       // This is a prefabricated skeleton CU.
       dwarf::Attribute attrDWOName = getDwarfVersion() >= 5
                                          ? dwarf::DW_AT_dwo_name

llvm/lib/DebugInfo/DWARF/DWARFExpression.cpp

static DescVector getDescriptions() {
   Descriptions[DW_OP_stack_value] = Desc(Op::Dwarf3);
   Descriptions[DW_OP_WASM_location] =
       Desc(Op::Dwarf4, Op::SizeLEB, Op::WasmLocationArg);
   Descriptions[DW_OP_GNU_push_tls_address] = Desc(Op::Dwarf3);
   Descriptions[DW_OP_addrx] = Desc(Op::Dwarf4, Op::SizeLEB);
   Descriptions[DW_OP_GNU_addr_index] = Desc(Op::Dwarf4, Op::SizeLEB);
   Descriptions[DW_OP_GNU_const_index] = Desc(Op::Dwarf4, Op::SizeLEB);
   Descriptions[DW_OP_GNU_entry_value] = Desc(Op::Dwarf4, Op::SizeLEB);
+  Descriptions[DW_OP_LLVM_form_aspace_address] = Desc(Op::Dwarf4);
+  Descriptions[DW_OP_LLVM_push_lane] = Desc(Op::Dwarf4);
+  Descriptions[DW_OP_LLVM_offset] = Desc(Op::Dwarf4);
+  Descriptions[DW_OP_LLVM_offset_uconst] = Desc(Op::Dwarf4, Op::SizeLEB);
+  Descriptions[DW_OP_LLVM_bit_offset] = Desc(Op::Dwarf4);
+  Descriptions[DW_OP_LLVM_call_frame_entry_reg] = Desc(Op::Dwarf4, Op::SizeLEB);
+  Descriptions[DW_OP_LLVM_undefined] = Desc(Op::Dwarf4);
+  Descriptions[DW_OP_LLVM_aspace_bregx] =
+      Desc(Op::Dwarf4, Op::SizeLEB, Op::SizeLEB);
+  Descriptions[DW_OP_LLVM_aspace_implicit_pointer] =
+      Desc(Op::Dwarf4, Op::SizeRefAddr, Op::SignedSizeLEB);
+  Descriptions[DW_OP_LLVM_piece_end] = Desc(Op::Dwarf4);
+  Descriptions[DW_OP_LLVM_extend] = Desc(Op::Dwarf4, Op::SizeLEB, Op::SizeLEB);
+  Descriptions[DW_OP_LLVM_select_bit_piece] =
+      Desc(Op::Dwarf4, Op::SizeLEB, Op::SizeLEB);
 
   Descriptions[DW_OP_convert] = Desc(Op::Dwarf5, Op::BaseTypeRef);
   Descriptions[DW_OP_entry_value] = Desc(Op::Dwarf5, Op::SizeLEB);
   Descriptions[DW_OP_regval_type] =
       Desc(Op::Dwarf5, Op::SizeLEB, Op::BaseTypeRef);
 
   return Descriptions;
 }
static bool prettyPrintRegisterOp(DWARFUnit *U, raw_ostream &OS,
                                   const MCRegisterInfo *MRI, bool isEH) {
   if (!MRI)
     return false;
 
   uint64_t DwarfRegNum;
   unsigned OpNum = 0;
 
   if (Opcode == DW_OP_bregx || Opcode == DW_OP_regx ||
-      Opcode == DW_OP_regval_type)
+      Opcode == DW_OP_regval_type || Opcode == DW_OP_LLVM_aspace_bregx)
     DwarfRegNum = Operands[OpNum++];
+  else if (Opcode == DW_OP_LLVM_call_frame_entry_reg)
+    DwarfRegNum = Operands[OpNum];
   else if (Opcode >= DW_OP_breg0 && Opcode < DW_OP_bregx)
     DwarfRegNum = Opcode - DW_OP_breg0;
   else
     DwarfRegNum = Opcode - DW_OP_reg0;
 
   if (Optional<unsigned> LLVMRegNum = MRI->getLLVMRegNum(DwarfRegNum, isEH)) {
     if (const char *RegName = MRI->getName(*LLVMRegNum)) {
       if ((Opcode >= DW_OP_breg0 && Opcode <= DW_OP_breg31) ||
-          Opcode == DW_OP_bregx)
+          Opcode == DW_OP_bregx || Opcode == DW_OP_LLVM_aspace_bregx)
         OS << format(" %s%+" PRId64, RegName, Operands[OpNum]);
       else
         OS << ' ' << RegName;
 
       if (Opcode == DW_OP_regval_type)
         prettyPrintBaseTypeRef(U, OS, DumpOpts, Operands, 1);
       return true;
     }
bool DWARFExpression::Operation::print(raw_ostream &OS, DIDumpOptions DumpOpts,
 
   StringRef Name = OperationEncodingString(Opcode);
   assert(!Name.empty() && "DW_OP has no name!");
   OS << Name;
 
   if ((Opcode >= DW_OP_breg0 && Opcode <= DW_OP_breg31) ||
       (Opcode >= DW_OP_reg0 && Opcode <= DW_OP_reg31) ||
       Opcode == DW_OP_bregx || Opcode == DW_OP_regx ||
-      Opcode == DW_OP_regval_type)
+      Opcode == DW_OP_regval_type ||
+      Opcode == DW_OP_LLVM_call_frame_entry_reg ||
+      Opcode == DW_OP_LLVM_aspace_bregx)
     if (prettyPrintRegisterOp(U, OS, DumpOpts, Opcode, Operands, RegInfo, isEH))
       return true;
 
   for (unsigned Operand = 0; Operand < 2; ++Operand) {
     unsigned Size = Desc.Op[Operand];
     unsigned Signed = Size & Operation::SignBit;
 
     if (Size == Operation::SizeNA)

llvm/lib/MC/MCDwarf.cpp

static unsigned getCIEVersion(bool IsEH, unsigned DwarfVersion) {
   }
   llvm_unreachable("Unknown version");
 }
 
 const MCSymbol &FrameEmitterImpl::EmitCIE(const MCDwarfFrameInfo &Frame) {
   MCContext &context = Streamer.getContext();
   const MCRegisterInfo *MRI = context.getRegisterInfo();
   const MCObjectFileInfo *MOFI = context.getObjectFileInfo();
+  const MCAsmInfo *MAI = context.getAsmInfo();
 
   MCSymbol *sectionStart = context.createTempSymbol();
   Streamer.emitLabel(sectionStart);
 
   MCSymbol *sectionEnd = context.createTempSymbol();
 
   dwarf::DwarfFormat Format = IsEH ? dwarf::DWARF32 : context.getDwarfFormat();
   unsigned UnitLengthBytes = dwarf::getUnitLengthFieldByteSize(Format);
const MCSymbol &FrameEmitterImpl::EmitCIE(const MCDwarfFrameInfo &Frame) {
   uint64_t CIE_ID =
       IsEH ? 0 : (IsDwarf64 ? dwarf::DW64_CIE_ID : dwarf::DW_CIE_ID);
   Streamer.emitIntValue(CIE_ID, OffsetSize);
 
   // Version
   uint8_t CIEVersion = getCIEVersion(IsEH, context.getDwarfVersion());
   Streamer.emitInt8(CIEVersion);
 
-  if (IsEH) {
-    SmallString<8> Augmentation;
+  if (IsEH) {
     Augmentation += "z";
     if (Frame.Personality)
       Augmentation += "P";
     if (Frame.Lsda)
       Augmentation += "L";
     Augmentation += "R";
     if (Frame.IsSignalFrame)
       Augmentation += "S";
     if (Frame.IsBKeyFrame)
       Augmentation += "B";
-    Streamer.emitBytes(Augmentation);
   }
+  if (MAI->supportsHeterogeneousDebuggingExtensions())
+    Augmentation += "[amd:v0.1]";
+  Streamer.emitBytes(Augmentation);
   Streamer.emitInt8(0);
 
   if (CIEVersion >= 4) {
     // Address Size
     Streamer.emitInt8(context.getAsmInfo()->getCodePointerSize());
 
     // Segment Descriptor Size
     Streamer.emitInt8(0);
if (Frame.Lsda)
       emitEncodingByte(Streamer, Frame.LsdaEncoding);
 
     // Encoding of the FDE pointers
     emitEncodingByte(Streamer, MOFI->getFDEEncoding());
   }
 
   // Initial Instructions
 
-  const MCAsmInfo *MAI = context.getAsmInfo();
   if (!Frame.IsSimple) {
     const std::vector<MCCFIInstruction> &Instructions =
         MAI->getInitialFrameState();
     emitCFIInstructions(Instructions, nullptr);
   }
 
   InitialCFAOffset = CFAOffset;
 

llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUMCAsmInfo.cpp

AMDGPUMCAsmInfo::AMDGPUMCAsmInfo(const Triple &TT,
   //===--- Global Variable Emission Directives --------------------------===//
   HasAggressiveSymbolFolding = true;
   COMMDirectiveAlignmentIsInBytes = false;
   HasNoDeadStrip = true;
   //===--- Dwarf Emission Directives -----------------------------------===//
   SupportsDebugInformation = true;
   UsesCFIForDebug = true;
   DwarfRegNumForCFI = true;
 
+  SupportsHeterogeneousDebuggingExtensions = true;
+
   UseIntegratedAssembler = false;
 }
 
 bool AMDGPUMCAsmInfo::shouldOmitSectionDirective(StringRef SectionName) const {
   return SectionName == ".hsatext" || SectionName == ".hsadata_global_agent" ||
          SectionName == ".hsadata_global_program" ||
          SectionName == ".hsarodata_readonly_agent" ||
          MCAsmInfo::shouldOmitSectionDirective(SectionName);

llvm/test/DebugInfo/AMDGPU/cfi.ll

 ; RUN: llc -mcpu=gfx900 -mtriple=amdgcn-amd-amdhsa -filetype=obj -o - %s | llvm-dwarfdump -debug-frame - | FileCheck %s
 
 ; CHECK: .debug_frame contents:
-; CHECK: 00000000 0000000c ffffffff CIE
+; CHECK: 00000000 0000001c ffffffff CIE
 ; CHECK-NEXT:   Format:                DWARF32
 ; CHECK-NEXT:   Version:               4
-; CHECK-NEXT:   Augmentation:          ""
+; CHECK-NEXT:   Augmentation:          "[amd:v0.1]"
 ; CHECK-NEXT:   Address size:          8
 ; CHECK-NEXT:   Segment desc size:     0
 ; CHECK-NEXT:   Code alignment factor: 4
 ; CHECK-NEXT:   Data alignment factor: 4
 ; CHECK-NEXT:   Return address column: 16
 ; CHECK-EMPTY:
 ; CHECK:   DW_CFA_nop:
+; CHECK:   DW_CFA_nop:
+; CHECK:   DW_CFA_nop:
+; CHECK:   DW_CFA_nop:
+; CHECK:   DW_CFA_nop:
+; CHECK:   DW_CFA_nop:
+; CHECK:   DW_CFA_nop:
+; CHECK-EMPTY:
 ; CHECK-EMPTY:
-; CHECK: 00000010 {{[0-9]+}} 00000000 FDE cie=00000000 pc=00000000...{{[0-9]+}}
+; CHECK-NEXT: 00000020 {{[0-9]+}} 00000000 FDE cie=00000000 pc=00000000...{{[0-9]+}}
 ; CHECK-NEXT: Format:       DWARF32
 ; CHECK-EMPTY:
 ; CHECK: .eh_frame contents:
 ; CHECK-NOT: CIE
 
 define void @func() #0 {
   ret void
 }

llvm/test/DebugInfo/X86/heterogeneous_proposal.s

+# RUN: llvm-mc -triple i686 %s -filetype=obj -o %t.o
+# RUN: llvm-dwarfdump -debug-info %t.o | FileCheck %s
+# RUN: llvm-dwarfdump -verify %t.o | FileCheck %s --check-prefix=VERIFY
+
+# Check that we can decode new ops described at
+# llvm/docs/AMDGPUUsage.rst#expression-operation-encodings
+
+# VERIFY-NOT: error: DIE contains invalid DWARF expression:
+# VERIFY: No errors.
+
+    .section .debug_abbrev,"",@progbits
+    .uleb128 1                      # Abbreviation Code
+    .uleb128 17                     # DW_TAG_compile_unit
+    .byte 1                         # DW_CHILDREN_yes
+    .byte 0                         # EOM(1)
+    .byte 0                         # EOM(2)
+    .uleb128 5                      # Abbreviation Code
+    .uleb128 52                     # DW_TAG_variable
+    .byte 0                         # DW_CHILDREN_no
+    .uleb128 2                      # DW_AT_location
+    .uleb128 24                     # DW_FORM_exprloc
+    .byte 0                         # EOM(1)
+    .byte 0                         # EOM(2)
+    .byte 0                         # EOM(3)
+
+    .section .debug_info,"",@progbits
+    .long .Lcu_end-.Lcu_start       # Length of Unit
+.Lcu_start:
+    .short 5                        # DWARF version number
+    .byte 1                         # DW_UT_compile
+    .byte 8                         # Address Size
+    .long .debug_abbrev             # Offset Into Abbrev. Section
+    .uleb128 1                      # Abbrev [1] DW_TAG_compile_unit
+# CHECK: DW_TAG_variable
+    .uleb128 5                      # Abbrev [5] DW_TAG_variable
+    .byte .Lloc_end-.Lloc_begin     # DW_AT_location
+.Lloc_begin:
+# CHECK-NEXT: DW_AT_location (
+    # CHECK-SAME: DW_OP_LLVM_form_aspace_address,
+    .byte 0xe9
+    # CHECK-SAME: DW_OP_LLVM_push_lane,
+    .byte 0xea
+    # CHECK-SAME: DW_OP_LLVM_offset,
+    .byte 0xeb
+    # CHECK-SAME: DW_OP_LLVM_offset_uconst 0x0,
+    .byte 0xec, 0x00
+    # CHECK-SAME: DW_OP_LLVM_bit_offset,
+    .byte 0xf4
+    # CHECK-SAME: DW_OP_LLVM_call_frame_entry_reg EAX,
+    .byte 0xf5, 0x00
+    # CHECK-SAME: DW_OP_LLVM_undefined,
+    .byte 0xf6
+    # CHECK-SAME: DW_OP_LLVM_aspace_bregx EAX+2,
+    .byte 0xf7, 0x0, 0x2
+    # CHECK-SAME: DW_OP_LLVM_aspace_implicit_pointer 0x1 +2,
+    .byte 0xf9, 0x1, 0x0, 0x0, 0x0, 0x2
+    # CHECK-SAME: DW_OP_LLVM_piece_end,
+    .byte 0xfa
+    # CHECK-SAME: DW_OP_LLVM_extend 0x0 0x0
+    .byte 0xfd, 0x0, 0x0
+    # CHECK-SAME: DW_OP_LLVM_select_bit_piece 0x0 0x0)
+    .byte 0xfe, 0x0, 0x0
+.Lloc_end:
+    .byte 0                         # End Of Children Mark
+.Lcu_end:

llvm/test/MC/ELF/AMDGPU/cfi.s

 # ASM: f:
 # ASM-NEXT: .cfi_sections .debug_frame
 # ASM-NEXT: .cfi_startproc
 # ASM-NEXT: s_nop 0
 # ASM-NEXT: .cfi_endproc
 
 # READELF: Section Headers:
 # READELF: Name              Type            Address          Off    Size   ES Flg Lk Inf Al
-# READELF: .debug_frame      PROGBITS        0000000000000000 000048 000028 00      0   0  8
+# READELF: .debug_frame      PROGBITS        0000000000000000 000048 000038 00      0   0  8
 
-# READELF: Relocation section '.rela.debug_frame' at offset 0xd0 contains 2 entries:
+# READELF: Relocation section '.rela.debug_frame' at offset 0xe0 contains 2 entries:
 # READELF-NEXT:     Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
-# READELF-NEXT: 0000000000000014  0000000300000006 R_AMDGPU_ABS32         0000000000000000 .debug_frame + 0
-# READELF-NEXT: 0000000000000018  0000000100000003 R_AMDGPU_ABS64         0000000000000000 .text + 0
+# READELF-NEXT: 0000000000000024  0000000300000006 R_AMDGPU_ABS32         0000000000000000 .debug_frame + 0
+# READELF-NEXT: 0000000000000028  0000000100000003 R_AMDGPU_ABS64         0000000000000000 .text + 0
 
 # READELF: Hex dump of section '.debug_frame':
-# READELF-NEXT: 0x00000000 0c000000 ffffffff 04000800 04041000 ................
-# READELF-NEXT: 0x00000010 14000000 00000000 00000000 00000000 ................
-# READELF-NEXT: 0x00000020 04000000 00000000                   ........
+# READELF-NEXT: 0x00000000 1c000000 ffffffff 045b616d 643a7630 .........[amd:v0
+# READELF-NEXT: 0x00000010 2e315d00 08000404 10000000 00000000 .1].............
+# READELF-NEXT: 0x00000020 14000000 00000000 00000000 00000000 ................
+# READELF-NEXT: 0x00000030 04000000 00000000