macOS support

[jab]

Since #83 (just titled "Mac") was closed via fe7a276, it's apparent that that issue was about failing with a better error message. Since it looks like there's no other issue tracking Mac support, I figured I'd create this one.

Thanks for releasing reptyr!

[james-see]

Seconding this. Would like support and wondering the LoE on doing this, seems like the Makefile could be adjusted to check and support the right gcc or am I missing something?

[kevans91]

@jamesacampbell Unfortunately it's a bit more involved than that- reptyr gets pretty deep into kernel debugging facilities that vary, usually quite wildly, from kernel-to-kernel. In the Mac OS case, they seem to have a very limited form of ptrace(2) inherited from *BSD, but it contains almost none of the necessary functionality to be useful. You're looking at writing platform shims that look like ptrace to reptyr (because that part is abstracted away in platform/ glue) but use whatever facility MacOS provides at a minimum. =(

[james-see]

@kevans91 thanks for that, I definitely was missing that context. That seems like a heavy lift.

[cooljeanius]

@jamesacampbell Unfortunately it's a bit more involved than that- reptyr gets pretty deep into kernel debugging facilities that vary, usually quite wildly, from kernel-to-kernel. In the Mac OS case, they seem to have a very limited form of ptrace(2) inherited from *BSD, but it contains almost none of the necessary functionality to be useful. You're looking at writing platform shims that look like ptrace to reptyr (because that part is abstracted away in platform/ glue) but use whatever facility MacOS provides at a minimum. =(

The macOS ptrace calls seem to work well enough for the macOS port of GDB; what does reptyr need to do with ptrace that gdb doesn't?

[kevans91]

@jamesacampbell Unfortunately it's a bit more involved than that- reptyr gets pretty deep into kernel debugging facilities that vary, usually quite wildly, from kernel-to-kernel. In the Mac OS case, they seem to have a very limited form of ptrace(2) inherited from *BSD, but it contains almost none of the necessary functionality to be useful. You're looking at writing platform shims that look like ptrace to reptyr (because that part is abstracted away in platform/ glue) but use whatever facility MacOS provides at a minimum. =(

The macOS ptrace calls seem to work well enough for the macOS port of GDB; what does reptyr need to do with ptrace that gdb doesn't?

As far as I know, gdb's not typically executing syscalls in the victim context as we need to in reptyr. For some specific points, I don't really see any equivalent to PT_{GET,SET}REGS (which we'll use to replace syscall arguments and rewind to the original syscall instruction in conjunction with PT_TO_SCE/PT_TO_SCX to advance to the next syscall and then break when we execute it). I don't recall any specifics beyond that, I haven't really looked at this much in the intervening five years since the message you uoted.