[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ATF tests hanging
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
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).
Main Index |
Thread Index |