I'm guessing @tromey will be best place to ward people off this one, but I notice gdb seems to be mostly written in c and given that quake3 was ported fairly painlessly to rust ( https://github.com/immunant/c2rust )... I'm left wondering could we, should we?
If a debugger was written in rust (even horrible non-idiomatic rust), it might lower the barrier to entry for people to contribute to it. Stranger things have probably snowballed...
Take a look at the code generated by c2rust. I cannot imagine anyone would want to work on such a code base. I would be like trying to contribute to a project given only an objdump of the compiler output in assembler.
Pretty much everything in c2Rust output is wrapped in "unsafe". So all the correctness guarantees of Rust are gone anyway.
You're probably right - it might well be more effort to tidy up than to make a new one.
I had a look at:
It not a bad start but might need some contributors.
Couple of things
- gdb has been in the midst of a transition to c++ since 8.0 (2017)
so running (I don't know if c2rust handles c++ at all) I imagine not.
- pre-c++ gdb still required patterns which are going to be hard to transition to idiomatic rust like reliance on a
setjmp based exception handling... this specifically is documented as likely wont ever support in c2rust's known limitations.
given that I don't really want to think about memory management, It's likely that the migration to c++ actually makes that situation somewhat better with RAII.
I think there could definitely be gains made from having a debugging frontend written in Rust, even if the backend is entirely either C or unsafe Rust. Even if gdb needs to use many low-level constructs to actually do the debugging, it doesn't need those for anything else: reading debug information, coordinating with a command line interface and matching up bits of binary code running with source code could all be done in safe rust.
This could mean making gdb even more robust than it is now, and as existing rust projects have proved, limiting unsafe code to particular program modules is still extremely useful even if you don't eliminate it entirely.
If the gdb team announced that they were considering rewriting portions of the codebase in Rust, I'd be excited.
With that said, I personally wouldn't be excited to work on a new rusty gdb as a hobby. It's a big project, and rewriting it in a reliable way will be hard. I like doing things which have a decent impact-for-the-work-done ratio, and this project really doesn't sound like it would.
What I want most in a debugging tool is reliability. But gdb already has reliability, and performing a rewrite is erasing all of that - it's starting from scratch. And for what, a more maintainable codebase? gdb is already being maintained, and even if we forked it, gdb would still exist, and it'll still be being maintained. Without new features and without the original developers, a rust fork has nothing to offer.
Edit: Rephrased my speculation in line with tromey's request below.
It makes little sense to me for GNU/Free Software Foundation developers to use Rust in the development of gdb, or any other program, when GNU has no compiler for Rust. How would they build it without using non-GNU software?
Of course as tromey points out below gdb does have support for Rust and when GCC supports Rust it would make sense to start to use Rust in GNU components.
In addition to what ratmice said, I am not sure that gdb is where you would want to start, anyway. Don't get me wrong -- I love working on gdb! However, there are aspects of its design that I would not duplicate in a new debugger.
Note that some components of a debugger written in Rust already exist. There is gimli, for reading DWARF. There is a (partial) implementation of the gdb remote protocol (this is important for remoting, but also it provides an easy way to bootstrap a debugger, by allowing the use of gdbserver or lldbserver instead of writing one's own low-level stuff initially). Importantly, Rust has a good async story.
It's still an enormous effort to write a debugger. I toy with the idea sometimes, but TBH I am more of (1) an incrementalist and (2) a GPL aficionado.
None of this is the case. For example, I have a very long history in GNU, and I wrote the Rust support already in gdb, continue to support that work, and finally I worked on the Rust compiler to improve its debug generation. I'd like to request that you not make statements like this in the future -- they are untrue and damaging to both Rust and GNU. Thank you in advance.
I should probably also add some reasons I think rust would be nice for writing a debugger...
The first thing that comes to mind is that rust has syntactic support for ranges, and could sertialize the range syntax as a structure rather than an array. Being capable of having a serialization format where range is a first class object, and doesn't have to convert them from a pair of numeric types.
I always thought it would be useful if gdb-mi the machine interface (i.e. the serialization interface to debugger frontends) could do so. As a lot of range like pairs get tossed back and forth, in both address spaces, source lines, etc.
Anyhow, there are some places I think it make the remote communication somewhat idiomatic, figure I'll edit this if anything else comes to mind.
I reworded my post in response to your request. I certainly did not intend anything negative toward Rust or GNU. Both of which I have great respect and admiration for and am deeply indebted to.
I was not intending to say that gdb could not/would not support debugging of Rust programs. That is clearly not correct.
My post, likely badly phrased, was intended as a speculation that GNU developers would be unlikely to use a language, Rust in this case, to develop GNU components, gdb in this case , for which there is no GNU compiler.
Or would they?
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.