I wish GDB is modular, and language supports are just plugins. This way adding language support doesn't have to go through upstream GDB developers

That's pretty much what lldb is (or will be, for some reason it's not yet final though it's been out for a while) for.

lldb is to llvm/clang what gdb is to gcc and co.

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.

Well, gdb used to "support" rust in that we pretended to be C and it supports C :)

Upstream support gets us:

- Native pretty print

- Expression evaluation. You can now `print foo(bar).baz().1` and it works

How smart is the evaluation?

What do you mean by "smart"?

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.

I mean what sorts of expressions it supports, and how lax are the typing rules of them, basically.

Ok indexing and function calls, makes sense. It won't dispatch on types at all for polymorphic functions I assume.

Right, types aren't involved much. IIRC method dispatch on preexisting monomorphizations work. Gdb will not monomorphize for you.

Trait methods don't work, though you can call them directly as functions if you wish.

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.

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've looked at the Python API, and it's not exactly good. I can look at the Scheme API, but after seeing the Python attempt, I'm not optimistic.

...I put in the star to say that the Python API didn't count, but forgot to actually elaborate on it.

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.)

What is missing in Python API? You can set breakpoints/watchpoints with gdb.Breakpoint.

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.

For reference => http://plan9.bell-labs.com/sys/doc/acidpaper.html

Do we really need yet another special ad hoc scripting language?

Only if your time is valuable.

what's the correlation?

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.

A stable standard will only really happen when people stop using nightly for what should be common stuff.

Latest example being Spyglass that was recently posted in HN.

This is why I always dowload mingw runtime of rust on windows.

Url changed from https://www.protocol96.com/blog/gdb-debugger-now-supports-th..., which points to this.

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...