Re: ATF tests hanging

[christos%zoulas.com@localhost (Christos Zoulas)]

On Dec 27,  8:20pm, martin%duskware.de@localhost (Martin Husemann) wrote:
-- Subject: Re: ATF tests hanging

| On Wed, Dec 27, 2017 at 08:17:46PM +0100, Kamil Rytarowski wrote:
| > The breakpoint behavior is MD specific. On x86 we execute the
| > instruction first and next report it in case of software breakpoint
| > (int3). On sparc we need to manually ADVANCE the Instruction Pointer.
| > 
| > We have a dedicated macro for this in src/sys/arch/sparc/sparc/trap.c
| 
| Yes, sure, e.g. for emulated instructions we advance over it before
| resuming, but for other traps (like a page fault) we just start again
| at the trapped instruction.
| 
| The question is what we should do with ptrace(PT_CONTINUE, .., (void*)1)),
| and the man page does not suggest we should ADVANCE here (at least in my
| reading).

So last time I looked into it, the behavior was processor and instruction
specific, for example: cvs diff -r1.116 -r1.117 src/sys/arch/vax/vax/trap.c 
Basically, if you know that resuming will cause you to fault again, you
either need to advance or exit. The problem is that if you advance+continue
and the faulting instruction did not work as expected, how does the program
know that the instruction did not work, or how to recover?

| > I cannot confirm now whether we should adjust it for the x86 behavior or
| > not, I would need to check it with existing debuggers, developers and
| > kernels for sparc to make sure.
| 
| ARM (after fixing PTRACE_BREAK_ASM) behaves the same as sparc*.

Good :-)

christos