CTF's simplicity means it can omit location lists, stack machines, and a lot of other machinery.

It is true that CTF doesn't know what scopes are, and that it will almost certainly never grasp local variables (unlike global-scope variables, which it understands already) -- but the backtrace section should be able to grasp what function parameters are, their names, types, and all but the oddest examples of locations. The idea is that you can get enough knowledge for 'bt' to work, and that you can then dig around in the values of the function parameters that the backtrace can show you. It's not a full debugger, but then it'll also be much smaller than DWARF and always present. (Of course, the backtrace section is still being designed, so all of this may change...)

The "always present" part allows for some very neat things to happen in future which seem to belong to languages much more dynamic than C. There are so many this comment box is far too small to contain them, but one small example. An API I've been vaguely thinking of adding to libctf, which requires no extensions to the current CTF file format, is this:

void *ctf_get_value_from_function (ctf_file_t *fp, const char *symbol, void *root, const char *path);

This is basically XPath for the C type system. You dig out the CTF section of a shared library via a ctf_open() call (giving you 'fp' above), find out the return value and args of the function "foo" you want to call by asking CTF, call it (perhaps via ffcall or dlsym) and stuff the return value in a suitable variable (call it "bar"), then you can call

ctf_get_value_from_function (fp, "foo", bar, ".memb_a.u_b.c");

which would look up the type of the return value of foo(), take 'bar' to point to that return value, and traverse the chain of structure/union members memb_a, then u_b from the resulting structure or union, then c from that, returning the value of c as the return value of ctf_get_value_from_function(). The above would be the equivalent of doing the second line of this at compile time:

some_type *bar = foo();
bar->memb_a.u_b.c

or perhaps

bar->memb_a->u_b.c

or anything similar.

Of course, you *can* do this now with shared header files at compile time -- but with this hypothetical new API, libctf would let you do it at *runtime*. No need to be a debugger and literally two or three lines of code. And obviously this syntax could be extended to support other languages once CTF supported them, and you could still call it from C perfectly well -- and you can't do *that* with shared header files at compile time. And it would always work without needing to get the user to install huge debuginfo packages, and with no perceptible delay.

(btw, I would recommend nobody try using the linker patches Jon has linked to here. They crash the assembler. New patches should land soon, and I'll follow up here when they do. This stuff is very bleeding-edge right now and debugging is ongoing. My TODO list is huge.)