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():
BUGS
On the SPARC, the PC is set to the provided PC value for
PT_CONTINUE and
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