Re: ATF tests hanging

[Martin Husemann <martin%duskware.de@localhost>]

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