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

Tamas Berghammer tberghammer at google.com
Tue Jul 7 02:31:54 PDT 2015


tberghammer added a subscriber: tberghammer.

================
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
 
----------------
labath wrote:
> 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 (?)
Based on my understanding these tests try to verify that the "s" (or the "vCont:s") packet only steps 1 instruction. For architectures where the instruction size is fixed we can compare the PC reported before the step and after the step but it won't work on x86 or with thumb


Repository:
  rL LLVM

http://reviews.llvm.org/D10954







More information about the lldb-commits mailing list