Hacker News Reader

Comment by cevn | Hacker News Reader

Can you use a debugger yet? This was a major roadblock for me when I tried to learn rust. (other than lldb)

Rust support landed in gdb 7.12 (released October 2016). It has some rough edges; and some missing spots (mostly caused by insufficient debuginfo).

I'm working full time on Rust debugging now. My basic plan is to write a Rust plugin for lldb (WIP branch https://github.com/tromey/lldb/tree/rust); then update LLVM, rustc, lldb, and gdb in sync to add support for missing features.

I'm interested in bug reports and other constructive feedback.

LLDB works well enough to sometimes be useful. I've used it with the VS Code native debugger extension [1].

I've encountered a couple annoyances:

A. Using rustc to link somehow removes debugging information from static libraries I wrote in assembly [2]. This is extremely annoying, but I haven't had time to really look into it and it seems others can't reproduce it.

B. There seem to be some occasional oddball problems when stepping through code. Like it'll skip lines, or stay on the same line for many steps. And also an annoyance regarding how that VS Code extension handles "Step Into" for functions you don't have the source for: you can easily get into an infinite popup situation and have to restart the debugger.

IMO the sad truth is that if a great debugger is a prerequisite to use a language, then you're limited to about 5 total languages.

[1] https://marketplace.visualstudio.com/items?itemName=webfreak...

[2] https://github.com/rust-lang/rust/issues/45218

> Like it'll skip lines, or stay on the same line for many steps.

I've never hit these problems, though I have the source for everything I'm compiling in Rust in general.

I've run into it before, but it's not usually too serious. It only usually happens on lines with compound expressions or chained calls like this:

  foo.into_iter().map(|x| x+1)
     .filter(|y| y > 2)

My working theory is that it's related to situations where there's multiple statements on the same source line (or inside a block inside a lambda).

Yeah, quite possibly. I feel like I've stepped through some pretty gnarly iterator chains and it's worked surprisingly well. It is rare that I actually need to turn to the debugger, so I could be mistaken.

So far I haven't encountered a problem that wasn't caught at compile-time.

However, your question prompted me to see if I could set a breakpoint and step through a program, and I was able to do it without much effort.

I have the "LLDB Debugger" extension in VSC installed. After that, the trick was to configure its launch.json to have the "program" property set to "${workspaceRoot}/target/debug/mandelbrot".

That's all it took.

Maybe I'd encounter some shortcoming trying to actually use it in anger, but I was happy to be able to do this much.

This is encouraging! In my experience, getting to this stage - where you've actually seen the thing successfully hit a breakpoint - is 95% of the hard work with debugging. I'm not a heavy debugger user, I prefer trace logging, rich type systems and tests for most problems, but then that one time when you have no choice but to "use it in anger", it simply has to be there.

I seem to run afoul of some obscure, ungooglable edge case almost every time I try to start a debugger I don't use very often, regardless of the platform. Of course this happens when I'm frustrated enough to be considering using a debugger in the first place, which is exactly when you don't want to be rage-googling why your debugger refuses to print symbol names, but only when you start it with exactly the arguments you need to start it with to trigger the bug. Or when you try to send an email more than 500 miles away Or print on a Tuesday. By that point, your debugger problem is worse than your original bug.

There's a strong sense from a vocal portion of the software development community that debuggers aren't really needed (not suggesting that this is you, just a general observation). Coupled with the fact that building a functioning debugging tool is no easy task, we end up in a situation where far too many platforms treat debugging as a second class citizen when it's really an essential feature, even if for some of us it's a feature of last resort.

Newer GDBs have native support; Visual Studio (not Code, but also Code)'s debugger works too (we generate pdb files). Older gdbs and lldb can use a plugin/script.

When was this? Rust has been able to pretend to be C for years, now, and debugs pretty ok. However until last year you could not do things like call functions (in gdb, lldb doesn't have support yet).

We're now moving towards making Rust have Rust-specific debuginfo for a better debugging experience. tromey (who has commented below) is working on this both for lldb and gdb.

I'm an Eclipse guy and when writing this [1] for fun, debugging in Eclipse worked fine (I'm on Fedora). Code completion via Racer mostly works (except some cases like recognizing the type of the try! macro's result).

[1] https://github.com/GreatAttractor/libskry_r

I've been using LLDB for well over a year with integration into VSCode for GUI based stepping through code, etc.

There's a minor inconvenience of setting up targets for the LLDB to launch tests, etc, but for when it's needed this isn't a huge effort to get going.

I've not yet tried IntelliJ's CLion integration, which I think I've heard is good.

GDB works like a charm! Works nicely with VSCode or any other visual tool for GDB as well

For some reason I can't see sources in GDB (both in tui and terminal modes). I've tried different versions from 6.x to 8.0.1 with no luck.

Is a debugger really a hard requirement for learning a language?

Learning no. Using, I think yes.

For what it's worth, while I would regularly use a debugger for C code, I've never once tried or had the urge to use a debugger on Rust code. (I've been using Rust for almost 4 years.)

I usually don’t use the debugger to debug language features, but rather my own logic. It’s very useful to step and inspect parameters when you can’t really see your own logic errors.

I have to say that my own experience over the last two years matches burntsusih's pretty close.

In the case of logic stuff Tagged Union/Enum types help me force logic at compile time. If I've got a particularly intractable logic problem a good coverage of unit tests works well to flush out any bugs and give me confidence when it comes to refactoring.

There's been a handful of times that I've wanted to reach for the debugger but a couple inspect()/println!() calls did the trick in those cases.

clion, atom(not sure), visual code support debugging

Reply on news.ycombinator.com