On Dec 27, 8:20pm, [email protected] (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
