[lldb] [llvm] [DWARF] Add DW_OP_LLVM_NVIDIA_mux vendor extension as a subop of DW_OP_LLVM_user (PR #216314)

[Scott Linder via llvm-commits]

================
@@ -208,6 +208,47 @@ TEST_F(DWARFExpressionCompactPrinterTest, Test_OP_LLVM_user_unknown_subop) {
                          "DW_OP_LLVM_form_aspace_address (2)>");
 }
 
+// DW_OP_LLVM_NVIDIA_mux carries an opaque selector, so the compact printer
+// cannot know its stack effect and must bail out naming both opcodes.
+TEST_F(DWARFExpressionCompactPrinterTest, Test_OP_LLVM_NVIDIA_mux) {
+  TestExprPrinterFailure({DW_OP_LLVM_user, DW_OP_LLVM_NVIDIA_mux, 0xa5, 0x01},
+                         "<unknown op DW_OP_LLVM_user (233) subop "
+                         "DW_OP_LLVM_NVIDIA_mux (13)>");
+}
+
+// The selector is a ULEB128 operand, so 165 encodes as two bytes.
+TEST(NVIDIAMux, Full_DW_OP_LLVM_NVIDIA_mux) {
+  const uint8_t Enc[] = {DW_OP_LLVM_user, DW_OP_LLVM_NVIDIA_mux, 0xa5, 0x01};
+
+  std::string Result;
+  raw_string_ostream OS(Result);
+  DataExtractor DE(Enc, true);
+  DWARFExpression Expr(DE, 8);
+
+  DIDumpOptions DumpOpts;
+  printDwarfExpression(&Expr, OS, DumpOpts, nullptr);
+
+  EXPECT_EQ(OS.str(), "DW_OP_LLVM_user DW_OP_LLVM_NVIDIA_mux 0xa5");
+}
+
+// A trailing operation must still decode, proving the selector consumed
+// exactly the two bytes of its ULEB128 encoding.
+TEST(NVIDIAMux, Full_DW_OP_LLVM_NVIDIA_mux_TrailingOp) {
----------------
slinder1 wrote:

How does that interact with parsing in LLVM, then? If it is really opaque, it seems like LLVM should not just go on parsing after seeing it, it should halt parsing and say "I don't know what the rest of this is, here is the encoded form: ..." or something

https://github.com/llvm/llvm-project/pull/216314