gdb has technically supported Rust for some time, although Rust has distributed a pretty-printing wrapper (rust-gdb) to fix variable naming and some other items, but having upstream support is pretty awesome.
It doesn't support running arbitrary rust code. But you can access fields and make calls and use indexing/ranges/etc. You can't do things like use an if block.
Seems good. Just as a random note: I tried to submit this URL, and so just upvoted. But the reason I originally chose that URL over the one the story is now about was because it focused on the Rust bit, whereas linking to the general notes and only pointing out Rust felt wrong. So good call, but just thought I'd mention that...
I wish GDB was a bit more like Acid, in that the debugger was really just a scripting language* that let you do things like set breakpoints at an address, read the symbol table and parse DWARF debug info, set watchpoints, and not much else.
Basically everything else that you would use at the source level could be built on top of those.
Maybe this is the start of a new underwear project: A debugger in [part of] the spirit of Acid, but built on top of the lldb library.
I believe this is true already? Rust used to pretend to be C, and got breakpoints/debuginfo for free. Python scripts could help with pretty printing. I'm not sure of subexpression evaluation is something a gdb Python script can do, but I see no technical barrier to this.
Having it in gdb itself means less work for people who want to use it. Rust ships with gdb/lldb pretty printers, but not everyone knows about them.
GDB can be extended using Guile Scheme. I am pretty ignorant when it comes to GDB, but I've seen people write Scheme extensions to help with V8 development and inspect certain C++ data structures more easily.
I use gdb's Python API all the time, and I'm really happy that they have it. It's good for custom pretty-printing (well, almost - I wish p vec[6] worked well and not just print vec if vec has a pretty printer defined for its type) and it's good for commands needing to access a bunch of state and print a custom summary/run external commands based on that (for instance, view an image object graphically.)
So when you say it's not good I guess you want to do other things (which?) - or else you mean that it's messy (if so I ought to say that I've seen much worse and in relative terms I'd say gdb's API is rather lovely.)
I hope this is indicative of plans to revive the rust gcc frontend. The existence of that frontend was a major plus for the language as a stable standard.
I don't think it is, this was an effort by Tom Tromey and me on the side, not something the gcc/gdb community decided to do.
Also, without a stable abi I'd caution against having a separate frontend. The language "standard" isn't ready yet, either; it doesn't exist as a single document.
27 comments
[ 3.2 ms ] story [ 65.1 ms ] threadUpstream support gets us:
- Native pretty print
- Expression evaluation. You can now `print foo(bar).baz().1` and it works
It doesn't support running arbitrary rust code. But you can access fields and make calls and use indexing/ranges/etc. You can't do things like use an if block.
Ok indexing and function calls, makes sense. It won't dispatch on types at all for polymorphic functions I assume.
Trait methods don't work, though you can call them directly as functions if you wish.
lldb is to llvm/clang what gdb is to gcc and co.
Basically everything else that you would use at the source level could be built on top of those.
Maybe this is the start of a new underwear project: A debugger in [part of] the spirit of Acid, but built on top of the lldb library.
Having it in gdb itself means less work for people who want to use it. Rust ships with gdb/lldb pretty printers, but not everyone knows about them.
...I put in the star to say that the Python API didn't count, but forgot to actually elaborate on it.
So when you say it's not good I guess you want to do other things (which?) - or else you mean that it's messy (if so I ought to say that I've seen much worse and in relative terms I'd say gdb's API is rather lovely.)
Also, without a stable abi I'd caution against having a separate frontend. The language "standard" isn't ready yet, either; it doesn't exist as a single document.
Latest example being Spyglass that was recently posted in HN.