================
@@ -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
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
