[Lldb-commits] [PATCH] D10954: [LLDB][MIPS] Added test case support for MIPS

[Pavel Labath]

labath added a subscriber: labath.

================
Comment at: test/tools/lldb-server/gdbremote_testcase.py:1261-1266
@@ -1260,2 +1260,8 @@
         self.assertTrue(state_reached)
+        expected_step_count = 1
+        arch = self.getArchitecture()
+
+        #MIPS required "3" (ADDIU, SB, LD) machine instructions for updation of variable value
+        if arch == "mips" or arch == "mips64" or arch == "mips32el" or arch == "mips64el":
+           expected_step_count = 3
 
----------------
clayborg wrote:
> Not sure why we have a test that is counting single steps of instructions? Of course they are going to vary. Maybe you can check with the original author and ask why we are doing this? This doesn't seem portable or like a very good thing to test? I would rather see breakpoints being set at source lines and stop before and after and verify that things changed than to have any tests that expect stepping to work in a specific way. All of the different architectures (arm, arm64, i386, x86_64, mips, mips64, hexagon, etc) have front/back ends that produce different DWARF line tables so even trying to make a test that does something like:
> 
> - set breakpoint 1 by file + line
> - run to breakpoint 1
> - test some initial condition
> - step over
> - step over
> - test something
> 
> are doomed to fail. We should be using breakpoints on file + line in order to test things so they work on all architectures and then the test should look like:
> 
> - set breakpoint 1 by file + line
> - set breakpoint 2 by file + line
> - run to breakpoint 1
> - test some initial condition
> - run to breakpoint 2
> - test something
As I understand it, these tests are supposed to verify behaviour of the lldb-server, sans lldb. This means they talk raw gdb-remote protocol over sockets and they don't have access to lldb functionality like parsing dwarf line tables.
That said, I don't have an idea how to make this more robust... Perhaps we don't need to care about the exact number of steps - it should be enough to verify that the state is reached within a reasonable number of steps (?)


Repository:
  rL LLVM

http://reviews.llvm.org/D10954