[Lldb-commits] [lldb] [lldb][RISCV] fix LR/SC atomic sequence handling in lldb-server (PR #127505)

[via lldb-commits]

================
@@ -0,0 +1,90 @@
+"""
+Test software step-inst
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestSoftwareStep(TestBase):
+    @skipIf(archs=no_match(re.compile("rv*")))
+    def test_cas(self):
+        self.build()
+        (target, process, cur_thread, bkpt) = lldbutil.run_to_name_breakpoint(
+            self, "cas"
+        )
+        entry_pc = cur_thread.GetFrameAtIndex(0).GetPC()
+
+        self.runCmd("thread step-inst")
+        self.expect(
+            "thread list",
+            substrs=["stopped", "stop reason = instruction step into"],
+        )
+
+        pc = cur_thread.GetFrameAtIndex(0).GetPC()
+        self.assertTrue((pc - entry_pc) > 0x10)
----------------
dlav-sc wrote:

>From what I understand, lldb runs the same test twice: the first one with the default dwarf debug info embedded in the binary (`dwarf` mode) and the second one with a binary compiled using `-dwarf-split`, which stores debug info in a separate file (`dwo` mode) (I might be mistaken about this exact workflow.)

I actually noticed a while back (about a year or more ago) that `-dwarf-split` doesn't work properly for riscv. `Clang` had been failing during compilation with an error stating that `-dwarf-split` is unsupported for riscv. However, more recently, clang seems to start compile something, but I'm not sure if the output is valid - some `dwo` tests show strange behavior, which might be related to issues with split debug info.

Regarding this specific test, it works as expected with standard `dwarf`, but there are problems with `dwo`:
* The test with incomplete `lr`/`sc` passes with `dwo`
* The branch test behaves strangely (doesn't even stop after step instruction)
* The standard `lr`/`sc` sequence test works but shows different PC offsets (`pc - entry_pc`)

After examining the binary a bit, looks like it uses different relocations than the dwarf version, resulting in 1-2 extra instructions in atomic sequences. This explains the different offsets in the same test but with different debug info formats .

This seems odd to me, as I wouldn't expect `-dwarf-split` to affect code generation. I've been meaning to investigate` -dwarf-split` more thoroughly. 

For now we could temporarily exclude `dwo` tests at all from consideration and use the offsets that corresponds to the standard `dwarf` case.

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