Current-Users archive

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

Re: ATF tests hanging

On 27.12.2017 20:20, Martin Husemann wrote:
> 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).

PT_CONTINUE (void *)1 resumes from the the current CPU-specific
Instruction Pointer value.

It could be explained more clearly about advancing the pointer.

There is also a sparc entry in BUGS in ptrace():

     On the SPARC, the PC is set to the provided PC value for
     similar calls, but the NPC is set willy-nilly to 4 greater than the PC
     value.  Using PT_GETREGS and PT_SETREGS to modify the PC, passing (void
     *)1 to ptrace(), should be able to sidestep this.

>> 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*.

I will check arm kernels and debuggers as well (and it will be easier
than sparc ones).

> Martin

Attachment: signature.asc
Description: OpenPGP digital signature

Home | Main Index | Thread Index | Old Index