Shmoocon 2016: Efficient Debugging For OS X

Developers love their macs, and if you look at the software that comes with it, it’s easy to see why. OS X is a very capable Unix-ey environment that usually comes on very capable hardware. There is one, huge, unbelievable shortcoming in OS X: the debugger sucks. GDB, the standard for every other platform, doesn’t come with OS X and Apple’s replacement, LLDB is very bad. After crashing Safari one too many times, [Brandon Edwards] and [Tyler Bohan] decided they needed their own debugger, so they built one, and presented their work at last weekend’s Shmoocon.

Building a proper tool starts with a survey of existing tools, and after determining that GDB was apparently uninstallable and LLDB sucked, their lit review took a turn for the more esoteric. Bit Slicer is what they landed on. It’s a ‘game trainer’ or something that allows people to modify memory. It sort of works like a debugger, but not really. VDB was another option, but again this was rough around the edges and didn’t really work.

The problems with the current OS X debuggers is that the tools used by debuggers don’t really exist. ptrace is neutered, and the system integrity protection in OS X El Capitan has introduced protected locations that can not be written to by root. Good luck modifying anything in /Applications if you have any recent Mac.

With the goal of an easy-to-use debugger that was readily scriptable, [Brandon] and [Tyler] decided to write their own debugger. They ended up writing the only debugger they’ve seen that is built around kqueue instead of ptrace. This allows the debugger to be non-invasive to the debugged process, inject code, and attach to multiple processes at once.

For anyone who has every stared blankly at the ‘where is GDB’ Stack Overflow answers, it’s a big deal. [Brandon] and [Tyler] have the beginnings of a very nice tool for a very nice machine.

27 thoughts on “Shmoocon 2016: Efficient Debugging For OS X

    1. Stop your misinformation campaign. OS X is not a ripped off KDE. It’s built on Darwin, which uses pieces of BSD, FreeBSD, and the Mach kernel. Apple has given back countless times, including all their work on WebKit (which looks nothing like the original KHTML that they forked), CUPS, zeroconf networking, the Swift language and runtime, Darwin Streaming Server, etc. They also support open source developers by hiring the lead developers and keeping the projects open (CUPS, LLVM, etc.)

    2. Everything is ripped off of everything else. Android ripped off iOS, iOS ripped off Android, Windows and Mac OS both ripped off Xerox.

      OSX has its flaws, but IMO it’s done more to help the *NIX community than it’s done to hurt it.

      1. Yup it still amazes me people in tech don’t understand how ideas spread. Walter Isaacson’s the Innovators is a great book I recommend to neophytes but hackers should know better.

    1. Most developers (mobile developers excepted) work on the platform they are targeting. As a result more work on OS X than on Linux. You can argue that Android is based on Linux, but Android developers can build from whatever platform they like and they are effectively targeting a Java runtime.

    2. I’ve been using some flavor of Unix as my primary desktop since 1988. That included Linux from roughly 1998 to 2006. I’ve been running OS/X since 2006. I’m only one of *many* long-time Unix users who have this switch.

          1. So it comes with a security system that protects non-technical users from malicious software, proficient users who find it annoying can easily disable it, and you can only disable it with physical access to the system.

            That’s a bad thing?

          2. You can also set a firmware password that you would have to type in before it lets you get to recovery mode. The only way to get around that is by brute forcing it with something like a Teensy.

  1. System integrity protection does *not* lock /Applications. It locks /System, /sbin, and /usr (with the exception of /usr/local). It can easily be disabled by booting to recovery mode (Cmd-R on startup), opening a terminal, and typing “csrutil disable”. Even with SIP, popular package managers such as Homebrew continue to work fine.

  2. I’ve actually found lldb to be a compellingly useful debugger… once I got over my initial expectations of it being a gdb-clone. This can be tough, because at first glance it looks very much like gdb. See for example the gdb-to-lldb command map:

    Thing is, by the words of its authors, lldb development is focusing more on making it a good debugging *framework* than a perfect CLI debugger, and as such there much of the work is going on in the Python API: (note: you can also view that same API doc formatted differently through local pydoc)
    Sure, it could be better documented, the tutorial is a bit light… but I argue that gdb’s doc is awful too, it just benefits from being around forever.

    One of the best things about gdb was DDD, a graphical frontend that could display graphs of your data structures. Sadly, it’s been unmaintained for years, I guess because of the pain of GDB’s “api” (DDD was really just screen-scraping gdb). I have hopes that LLDB’s Python API will make alternatives much easier to write and maintain.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.