This project needs engineers! Read on and see if you are a good fit...

How did this come about?

Back in May of 2013, Valve and RAD decided that the most important tools holding back Linux development were high-end graphical and code debuggers. We started collaborating on building them.

The graphics debugger, VOGL, was released in January 2014 and is already a great graphics debugging tool for Linux. But new development is currently on hold while GL 5.0 shakes out. Mike Sartain at Valve runs this project.

The code debugger is still in development. We started by working on improvements to LLDB, but ended up deciding to start our own codebase from scratch in December 2013.

Why make a new source-level debugger?

To put it bluntly, debugging on Linux is just really bad. We believe it is the biggest roadblock to great software for that platform. Don't get us wrong - debugging on Windows isn't great either. But the standard Visual Studio debugger is still much better than anything on Linux.

So we want to make Linux debugging as good as Windows debugging. And then we want to make both better - much better. There are so many better debugging tools that we can imagine having, and yet even today's best debuggers provide barely any functionality that wasn't in debuggers twenty years ago.

Also, we think there's a lot of value in having one great debugger that you can use on every platform. RAD develops software for roughly 18 platforms now. A big part of the friction of a new platform is dealing with different toolsets.

Compilers, linkers and runtimes are all hard to deal with, certainly, but you typically finish setting those up in a few days or weeks. The debuggers, on the other hand, are tools you have to use every day for as long as you develop on that platform!

What's involved?

Our first step is just making a standard debugger. There are four big pieces to this: low-level debugging services for each platform (process control, breakpoints, memory reading, etc), debug info parsing (DWARF, PDB, etc.), the debugger data framework, and the debugger UI itself.

The low-level debugging services are already working on Linux and are implemented on Windows, but we haven't yet tackled consoles or mobile operating systems. Debug info parsing is just getting started - we are handling part of DWARF, but there's still a ways to go before it's all implemented, and PDB hasn't been implemented at all yet. Both of these are ongoing maintenance jobs, too, since debugging info is complex and how compileres output it can often change or differ from what is documented.

The debugger data framework is under extensive development now. This is the layer that handles all of brokering and buffering of data coming from local and remote targets. This layer is usually wrapped up in the UI layer, but we split it out to allow UIs and visualizers to be added quickly and easily (more on this in a bit).

The UI right now is just a simple QT app that renders what the debugger application framework exposes. The idea is that, if things are organized in the framework well, then the UIs don't need to add anything special to automatically handle new platforms and new types of data when new platforms are added to the low level services. The UI will need lots of work when the framework is farther along, and QT will eventually be replaced with something else entirely.

What's after that?

Tons of stuff. Tons and tons and tons of stuff. Debuggers have not substantially evolved since the first Turbo Debugger in 1988!

For example, we have had GUI debuggers for 20 years now, and we can't see bitmaps! We can't hear sound buffers. We can't view vertex arrays. We can't graph values over time. We can't even load a debugging session from yesterday and review it! We have a long way to go.

Debugging is desperate need of updating, and we see as a long term project. We'll be adding visualizers, new debugging workflows (step through code on multiple platforms at the same time for example), and new features for a long time.

But that's all going to start in mid-2015, after we have built this first, basic, debugging platform.

What will the licensing be?

We have no idea right now. We're just trying to make something cool first.

What do we need?

Right now, we're immediately looking for someone to work on the low-level debugging services stuff. Richard Mitton has written a ton of great code here over the last year, but this level requires a lot of ongoing maintenance, since the toolchains change so much. There will also be work in updating interfaces and API as the debugger application framework requires.

This position needs to be a smart, low-level person who writes meticulous, careful, test-driven code (everything stacks on top of this, so it needs to be stable). They need to be good with reverse-engineering data formats when toolchains and specs diverge. This will be low-level C/C++ and assembly work.

We also need a great custom UI coder, someone who can write a full user interface from scratch with a mind towards advanced data visualization and extremely fast response times. We want the debugger to have a front end that feels great to use and isn't constrained to the lame set of basic widgets that exist in traditional UI systems. The code style here is a bit different - you will write a LOT of code here, jumping around writing stuff, coming back, rewriting it, etc. It is less test-driven and more experimental, where you write things different ways and move quickly. This will be C and C++ work.

We would like both of these positions to be in Seattle (eastside in Bellevue), but we can talk if you are awesome. If you are interested, email us at jobs(at)radgametools.com