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.
OS X still has that type of error message? The little bomb and IIRC, the accompanying car crash noise?
No.
Would be nice if a.. I dunno… a more current error GUI was used…
Just a thought there.
OSX is ripped off BSD and KDE. And Apple never gave anything back either. Scum.
Darwin ? https://en.wikipedia.org/wiki/Darwin_%28operating_system%29
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.)
Not to mention Clang and how the Clang guys woke the GCC team from their deep slumber.
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.
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.
And I’ll just leave this here…
https://www.youtube.com/watch?v=yJDv-zdhzMY
Most development work does not need a shiny silver case or clunky insecure operating system and MOST developers know that and instead use Linux.
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.
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.
You can actually disable the system protection in El Capitain and is fairy easly…
How?
Reboot to recovery mode (Cmd-R on startup), open a terminal, and type “csrutil disable”. Done.
Any system is easy to compromise when you have physical access….
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?
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.
This page seems to have pretty nice instructions:
https://www.quora.com/How-do-I-turn-off-the-rootless-in-OS-X-El-Capitan-10-11
https://duckduckgo.com/?q=disable+the+system+protection+in+El+Capitain — literally pasted from op’s comment.
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.
Also, GDB is installable, you just have to jump through a few hoops to code sign it. http://www.patosai.com/blog/post/installing-gdb-on-mac-os-x-yosemite
You can install GDB through MacPorts/Homebrew and manually sign it, so that the System Protection will allow you to use it. I don’t know how far you can go with that, but I’m using it to debug own C/C++ code under El Capitan – simple stuff; so far, no problems. The steps are detailed here: http://ntraft.com/installing-gdb-on-os-x-mavericks/ (it’s for Mavericks, but the steps are identical for El Capitan).
“El Capitan has introduced protected locations that can not be written to by root”
what about reading and copying can you read and copy the data in the protected places?
El Crapitan == Windows Vista
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: http://lldb.llvm.org/lldb-gdb.html
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: http://lldb.llvm.org/python_reference/index.html (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.