On 28.12.2017 13:47, Martin Husemann wrote: > On Wed, Dec 27, 2017 at 08:33:48PM +0100, Kamil Rytarowski wrote: >> This is not a x86 bug. >> >> It's an idiom in x86 to: >> - write software breakpoint >> - execute instruction (& move EIP/RIP) >> - detect trap >> - report to debugger >> - rewind IP >> - write original code >> - [offer prompt to a user; interaction; etc] >> - option to resume from the retrieved instruction >> >> There is a different behavior with hardware assisted (debug registers) >> instruction trap. As we trap before the execution of an instruction and >> there is no need to rewind the IP. >> >> In general these specific nits are to be handled in a debugger. > > Yes, but not in your test program. > I've designed it with lack of PT_WRITE_I/PIOD_WRITE_I usage in mind, to simplify the test case. It requires manual handling of RIP for some ports. >> Of course, we can try to streamline the behavior in all ports to behave >> exactly the same way. The SPARC behavior is certainly mild from a >> debugger point of view. > > I don't understand why you consider the x86 one more natural, you trap > on the breakpoint and that is where %pc is, you replace the breakpoint > instruction with the original and PT_CONTINUE, no need to play with > the IP. > I don't want to argue that one of them is more natural than the other. As I have noted, on x86 there are both characteristics available (software and hardware breakpoint are different in terms of EIP/RIP). > Also exactly this behaviour is needed for the %npc != (%pc + 4) case you > cited in the other mail (which is not a bug in our implementation, but > a restriction of the PT_CONTINUE interface where only a single address > to resume from may be specified). > > Martin > I will adopt this test for other CPUs.
Attachment:
signature.asc
Description: OpenPGP digital signature