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. > 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. 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
