This is an archive of the discontinued LLVM Phabricator instance.

Pull GetSoftwareBreakpointPCOffset into base class
ClosedPublic

Authored by labath on Sep 26 2018, 12:49 AM.

Details

Summary

This function encodes the knowledge of whether the PC points to the
breakpoint instruction of the one following it after the breakpoint is
"hit". This behavior mainly(*) depends on the architecture and not on the
OS, so it makes sense for it to be implemented in the base class, where
it can be shared between different implementations (Linux and NetBSD
atm).

(*) It is possible for an OS to expose a different API, perhaps by doing
some fixups in the kernel. In this case, the implementation can override
this function to implement custom behavior.

Event Timeline

labath created this revision.Sep 26 2018, 12:49 AM
krytarowski accepted this revision.Sep 26 2018, 1:08 AM
This revision is now accepted and ready to land.Sep 26 2018, 1:08 AM

I was wondering whether we want to normalize this inside the kernel and always advance the Program Counter.. but it's easier to manage it in userland.

I was wondering whether we want to normalize this inside the kernel and always advance the Program Counter.. but it's easier to manage it in userland.

I am generally in favour of keeping the kernel simple, particularly when ptrace is concerned. However, there is one difference in behaviour that annoys me. Right now, if an application itself inserts a trap into it's source code, on intel it will be easy to resume it from debugger simply by continuing. OTOH, on arm, the user will have to manually update the PC first. So I am not sure which is better here...

This revision was automatically updated to reflect the committed changes.

I was wondering whether we want to normalize this inside the kernel and always advance the Program Counter.. but it's easier to manage it in userland.

I am generally in favour of keeping the kernel simple, particularly when ptrace is concerned. However, there is one difference in behaviour that annoys me. Right now, if an application itself inserts a trap into it's source code, on intel it will be easy to resume it from debugger simply by continuing. OTOH, on arm, the user will have to manually update the PC first. So I am not sure which is better here...

Right now I defer this into future. We still need to fixup PC in kernel debuggers... on the other hand in order to advance the register manually on an arbitrary ISA we might need to guess instruction size. It's better to guess it in userland.