Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ATF tests hanging

On Dec 27,  8:20pm, (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 :-)


Home | Main Index | Thread Index | Old Index