[llvm] [llvm-objdump] Fix output corruption when DWARF reg-name callback misses. (PR #200975)

[James Henderson via llvm-commits]

================
@@ -0,0 +1,302 @@
+## Regression test for the llvm-objdump LiveVariable::print buffer-and-flush
+## fix. PR /#192353 added an ASCII-packed virtual-register decode fallback to
+## the compact DWARF expression printer. llvm-objdump's GetRegName lambda
+## used to write "<unknown register N>" to the output stream as a side
+## effect before returning empty; when the new fallback then succeeded, the
+## decoded name was appended, producing output like
+## "<unknown register 2454065>%r1".
+##
+## This test exercises the buffer-and-flush fix end-to-end with four
+## variables, each with a different DWARF location, covering the
+## interesting interactions between the lambda's miss and the compact
+## printer's per-op pass:
+##
+##   x: DW_OP_regx ULEB128(0x257231)
+##      Single reg, lambda misses, ASCII fallback rescues -> printer
+##      returns true, buffer discarded, renders "%r1". (Target fix.)
+##
+##   y: DW_OP_regx ULEB128(0x257231), DW_OP_plus
+##      Lambda misses on the regx (ASCII fallback rescues inside the
+##      printer's stack), but DW_OP_plus is not handled by the compact
+##      printer so it bails with "<unknown op DW_OP_plus (34)>" written
+##      directly to OS and returns false. The buffer is then flushed,
+##      producing the rescued reg's miss marker as a trailing false
+##      alarm. This is the multi-op pile-up case: noisy but not the
+##      original corruption.
+##
+##   z: DW_OP_regx ULEB128(100)
+##      Reg num 100 is below the ASCII validator floor, so the fallback
+##      also rejects. Printer returns false from the reg-failure path
+##      with empty OS; the buffer flush surfaces the single
+##      "<unknown register 100>" marker -- same content as pre-fix.
+##
+##   w: DW_OP_regx ULEB128(0x257231), DW_OP_regx ULEB128(0x257232)
+##      Two regs, both ASCII-rescued -> Stack ends with size 2 instead
+##      of 1, printer writes "<stack of size 2, expected 1>" to OS and
+##      returns false. Buffer flush appends both false-alarm reg
+##      markers behind that, producing the multi-marker pile-up the
+##      buffer-and-flush model is least graceful about.
+
+# RUN: llvm-mc -triple armv8a--none-eabi < %s -filetype=obj -o %t.o
+# RUN: llvm-objdump %t.o -d --debug-vars=ascii | FileCheck %s
+
+# CHECK: 00000000 <foo>:
+# CHECK: x = %r1
+# CHECK: y = <unknown op DW_OP_plus (34)><unknown register 2454065>
+# CHECK: z = <unknown register 100>
+# CHECK: w = <stack of size 2, expected 1><unknown register 2454065><unknown register 2454066>
+# CHECK-NOT: <unknown register 2454065>%r1
+
+	.text
----------------
jh7370 wrote:

> This test is a copy of the test llvm/test/tools/llvm-objdump/ELF/ARM/debug-vars-wide-chars.s, and modified(with the help of LLMs) the debug info-related sections for the purpose of showcasing this behavior.

As noted, I think you need explanations for how one would recreate this input, in test code itself. It doesn't necessarily need to be line-by-line annotations, but if the changes are small, you can just put the original code in a comment next to the modified code.

> and modified(with the help of LLMs)

Don't forget that the LLVM AI Policy requires attribution _in the PR description_ to LLMs when they are used significantly to create a PR. This would include generating test inputs.

> Is the pile-up an accepted behavior change?

If I'm understanding things correctly, your change isn't making things significantly worse; it's just reordering them and then only when things are invalid anyway. If so, this looks good to me, but would be worth @slinder1's opinion too.

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