Clear breakpoints so that gdb will not single step

[lz-bro]

riscv-tests/debug/gdbserver.py

Lines 2134 to 2141 in 67e7759

	else:
	assertIn("Failed", output)
	self.gdb.b("main_post_csrr")
	output = self.gdb.c()
	assertIn("main_post_csrr", output)
	main_post_csrr = self.gdb.p("&main_post_csrr")
	assertEqual(self.gdb.p("$pc"), main_post_csrr)

If there's a breakpoint set, gdb will send vCont;s:0;c:0, so cpu will execute 2 instructions when count is set to 1, with breakpoints cleared, gdb will send vCont;c.

[aap-sc]

@lz-bro while this simplification is useful I think it would not hurt to check both cases (the one where debugger does single step and the one when it doesn't). Do you have any reason for changing the test aside from simplication? (Likethis test fails in your environment, maybe)

[lz-bro]

@lz-bro while this simplification is useful I think it would not hurt to check both cases (the one where debugger does single step and the one when it doesn't). Do you have any reason for changing the test aside from simplication? (Likethis test fails in your environment, maybe)

Our hardware only supports count 1 and it is hard-wired to 1. #516
Openocd log show that if there's a breakpoint set, gdb will send vCont;s:0;c:0, and hart executed 2 instructions. But with breakpoints cleared, gdb will send vCont;c, hart executed 1 instruction.
I'm not familiar with gdb, but some comments from this repository caught my attention:

riscv-tests/debug/gdbserver.py

Lines 2004 to 2017 in a7c1a56

	# There's a breakpoint set, so gdb will single step. You can't single
	# step an unavailable target, so gdb should get a message to that
	# effect.
	self.test_resume(c_expect="unavailable")
	# Delete breakpoints
	self.gdb.command("delete")
	self.server.set_available(
	[h for h in self.target.harts if h != self.hart])
	# Resume again. With breakpoints cleared, gdb will send vCont;c instead
	# of step. There should be no error this time, since there is no
	# observable difference between an unavailable thread and a running
	# thread.

[aap-sc]

Our hardware only supports count 1 and it is hard-wired to 1. #516

@lz-bro but this renders this specific test incompatible with your HW. At least this is my understanding.

The intention of this test is to check that the processor is halted after exactly 2 instructions.

Openocd log show that if there's a breakpoint set, gdb will send ...

This is expected behavior for GDB. My point is that if we set an "icount" trigger set to with icount = 2, both scenario should work (the one where we don't remove breakpoint and the one where we do remove it).

[aap-sc]

@lz-bro ahh.. I've missed this part of this test:

        if self.target.icount_limit > 1:
            assertNotIn("Failed", output)
        else:
            assertIn("Failed", output)
            self.gdb.b("main_post_csrr")

I see. So my point is that maybe the deletion of breakpoint should be conditional too?

[lz-bro]

@lz-bro ahh.. I've missed this part of this test:

        if self.target.icount_limit > 1:
            assertNotIn("Failed", output)
        else:
            assertIn("Failed", output)
            self.gdb.b("main_post_csrr")

I see. So my point is that maybe the deletion of breakpoint should be conditional too?

Yes, the deletion of breakpoint could be conditional, I think this will not affect anything. Like "monitor riscv icount clear", if self.target.icount_limit == 1, there is will no triggers to clear.