Could somebody point me to (or explain to me) how to use rust-gdb in order to debug rust code?
I know this is kinda open question but some hints would be really appreciated.
Thank you.
1 Like
I don't know if the answer to your question is in here but if you want to know how to use Vim for Rust development listen to the master of it: "Desktop and editor setup for Rust development" by Jon Gjengset Desktop and editor setup for Rust development - YouTube
Although I get the feeling Jon is not much into low level debuggers like GDB.
1 Like
Thanks, will take a look.
As for low level debuggers, I am not sure I follow you.
I am pretty certain, he doesn't explain his debugger setup in this video.
Any Vim+GDB tutorial should work, because rust-gdb is just a thin wrapper that preloads helper scripts for pretty-printing Rust types.
Personally, I just run GDB separately, and I don't often need that level of debugging given Rust memory safety.
OK, forget the "low level" part. Think just "debugger".
To be honest, after decades of programming I don't know what people do in debuggers all day long.
I write some class/struct/methods/functions.
I write some tests for them.
If they work I move on.
If they don't the problem is usually clear with some code review.
If I get desperate a sprinkling of asserts or debug!() usually nails the problem.
This is even more the case with Rust that does not leave the possibility of making accidental memory usage and race condition errors to blow you out of the water at random.
You can count the number of times I have been desperate enough to break out a debugger over the years on a hand or two. Usually involving code running on embedded systems. And most of the time they were of no help. An oscilloscope or logic analyzer were more useful.
People writing code that has to work, think aircraft control systems, are not using debuggers to ensure their code is correct.
1 Like
Wow...
Just FYI, debuggers are used not to ensure that the code is correct...
1 Like
I don't follow what you mean. It's right there in the name "debuggers". That is to say a tool to help finding bugs. And what is a "bug"? A bug is an incorrectness in your code.
Now puzzle me this:
If you are spending some hours stepping through your code to see why it does not work, or setting break points to see what does or does not happen, why are you not spending that time on writing tests to demonstrate that it does work as expected?
The former is work you might have to do over and over again as your code evolves.
The latter is an automated, documented, test that can be repeated, at no effort well into the future.
1 Like
Thanks, will try that.
I really don't understand why people have the perception (false btw) that debuggers are used only to debug memory corruptions...
Perhaps it would help if you could tell us what it is you actually do with a debugger?
An obvious answer is that one can use a debugger to check for logical errors in the code. Check that for some input to some blob of code produces the correct output.
Fine, why then are you wasting time doing that in a debugger? Why not have test in place that can be run at will, repeatably, at anytime and can be documented well?
What else do you do with a debugger?
Program control flow in multithreaded application. You cannot write tests that will show you how different parts of program interact with each other. << This is just one of literally tens if not hundredths situations where nothing but debugger will do.
If debuggers were useless as you seem to suggest...
Ah, good you brought that up.
Having had to fight with "weird" problems in multi-thread, multi-core/processors systems for years I have never figured out how a debugger like GDB is of any help what so ever. Typically they are more of a hinderance than a help.
How do you do that?
Debuggers are not totally useless. I recall trying to track down such a multi-processor problem one time. Everything seemed to go to hell after a certain synchronization instruction. Think "lock exchange" in x86. Turned out the version of the in-house design processors we were testing against did not have that instruction implemented yet!
I consider that to be kind of extreme.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.