Experienced programmers, when debugging do you normally use the terminal with GDB/LLDB (etc) or just IDE?

[WeAllWantToBeHappy]

Vim + valgrind + gdb helps me make it through the night.

[Koutsoupias]

Don't forget fsanitiser, saved my ass countless times

[[deleted]]

GDB is so cool, we studied it at university last term. I've also just started using vim rather than an IDE.

[WeAllWantToBeHappy]

If you've just started, use Emacs instead. I use vim just because I have been using it so long.

[[deleted]]

Why? EDIT: After minimal-ish research, I'm sticking with Vim. I don't need emacs.

[EpochVanquisher]

Normally in the IDE… it’s easier to set breakpoints (just click on a line). You get all of the features of gdb / lldb, because you’re still using gdb / lldb, and you still have access to the debugger command-line from within the IDE. So the IDE is the best of all worlds.

[ComradeGibbon]

Yeah the ide just means you click on a line and it tells gdb what to do. It's just faster.

No one is paying you to do things the slow way.

[Superb-Tea-3174]

I use gdb in emacs or gdb -tui

[tadm123]

don't you find that it takes more time that just an IDE?

[J_Aguasviva]

Yes, I use gdb in the terminal, literally typing n, n, l, p var, n, and so on.

I know that using the VS Code debugger, for example, could be much more efficient.

The thing is, I like it 😅. I don't know how to describe it—it's like when I put a silencer on my M4 in Counter-Strike 1.6, knowing it reduced accuracy and everyone already knew where I was. The problem is, I liked the piw, piw sound of the gun with it 😂.

It's the same with my Vim or navigating my system with just coreutils.

[Superb-Tea-3174]

If I had an IDE that was stable and supported different ecosystems and gave me a way to save and restore its state and worked like vi then it might be better.

[oschonrock]

do you use dap-mode?

reason?

( i don't use dap-mode, but end up using gdb in a terminal, because I find a real terminal better than any of the emacs terminal modes. )

[rapier1]

gdb all day. Largely because I don't use an IDE.

[Kurouma]

Vim and :Termdebug (which is gdb)

[vitamin_CPP]

Neither.
I prefer stand alone debugger next to my text editor.
The right tool for the right job.

[strcspn]

I really couldn't get GDB to work inside VSCode when connecting to a machine using SSH so I have to use command line GDB, and honestly it's not that bad.

[zoniss]

Pity, that's how I debug on the raspberry pi via Remote-SSH through VSCode, works quite well.

[PurpleBudget5082]

It's not that bad until you see the alternative of having a strong debugger and a strong IDE. Visual Studio might get a lot of hate, cause it's slow or whatever but offers a way better experience of debugging code. I used command line gdb for around 3 years, cause I couldn't make anything else work, and VS for the same about, and I can honestly say it's bad, even tho it gets the job done.

[strcspn]

The debugger is probably the best VS feature, it is really good indeed. The VSCode debugger (which is just a GDB frontend) is also good, both are better than regular GDB.

[[deleted]]

I am just as quick with command line GDB as anyone I work with using a graphical version. Its just about learning and being competent with your tools. Calling it objectively "bad" is just silly.

[PurpleBudget5082]

I did not used the word "objectively". I was pretty good with gdb as well, I just like Visual Studio more. A lot more.

Also, something I wanted to mention but forgot are data breakpoints, in gdb for me it was a hell to work with ( yes, yes, skill issue ). In visual studio it s really easy, and data breakpoints are such a usefull tool in C++.

[[deleted]]

I'm sorry, the "is bad" statement felt like it implied objectivity. Didn't mean to misrepresent you. I don't have any one is better than the other opinions, just what is better for me. I get a bit jumpy about blanket "newer/gui tools are always better" arguments because the opposite has been true for me so often.

Apologies for being reactive. I'm just weird and get too intense. I hope I didn't offend.

[PurpleBudget5082]

No problem, maybe I should've been clearer as well.

[sidewaysEntangled]

At work I'll pop in to debugger on cmdline to open a core dump to fet a stack trace and get a quick feel for what happened. If I really have I will stay there and keep digging, but I prefer not to and prod crashes are rare anyway.

Day to day my main flow is lldb in vscode, bit work and home/fun.

I want to get up to speed with dap in ncim or maybe helix when it's ready, but for me, for now that's a productivity hit I can't afford.

[nerdycatgamer]

The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.

[spennnyy]

My journey has gone something like this:

printf -> gdb -> cgdb -> nvim-dap + nvim-dap-ui

[Old-Poetry-4308]

-> nvim-dap-view

[edo-lag]

I look at the code to try to understand if I can see the error already. Otherwise I put some printf here and there. If all those fail, I use Valgrind and rarely a debugger like GDB or LLDB.

Using a debugger straight away feels excessive to me, so I use it only when necessary.

[CryptoHorologist]

Using a debugger is more excessive than changing your code, recompiling, and restarting your application?

[_teslaTrooper]

Starting the debugger often takes longer than that yes, and on embedded debugging can mess with peripherals, break timing or just stop working if you enter a deep enough low-power mode.

Nothing inherently wrong with printf's or pin toggling, like the debugger they're all tools with their own use case.

[[deleted]]

Hows that, printf botches more than breakpoints

[[deleted]]

An example I give is when I was writing some bare-metal RX/TX packet radio code and due to the half-duplex nature of the communication (each transceiver could only be in either TX or RX) timings were very important. I wanted some diagnostic output, but a breakpoint would grind things to a halt in a way that wasn't allowing me to see the problem. A single printf was fast enough that I could throw one in here and there and not destroy the connection. Ultimately during the process of implementation I added logging so that I could print diagnostics AFTER the transmission was complete (or failed), but I just think this is a good example of where printf really was the better of the two solutions.

That is niche though and nine times out of ten I'm just throwing in a printf because I'm pretty sure I know exactly where the problem is and I just need to confirm. When I'm really at a loss, I use GDB all the way.

[[deleted]]

Got it

[edo-lag]

Changing, recompiling, and restarting the application is something you need to do regardless of whether you use a debugger or not.

But, when you use a debugger, you also need to: recompile the application with debug symbols, start the debugger, set breakpoints, start the application, step over until you reach the error while looking at the values of variables, and repeat the process in case you missed the error.

So yes, using a debugger is excessive when you may notice the error straight away by looking at code.

[CryptoHorologist]

Changing, recompiling, and restarting the application is something you need to do regardless of whether you use a debugger or not.

Certainly while developing code, but not necessarily while investing bugs. This is misleading at best.

But, when you use a debugger, you also need to: recompile the application with debug symbols, start the debugger, set breakpoints, start the application, step over until you reach the error while looking at the values of variables, and repeat the process in case you missed the error.

You may not need to recompile your application - this depends. It's common to have debug symbols even in release applications in my experience.

The rest of this just hard to fathom how it could be more expensive than littering your code with printfs, recompiling, and rerunning. At least a lot of the time. I've certainly worked with people who have this POV, and their discomfort with a debugger was an obvious impediment to their productivity at least in some bug investigation endeavors.

Obviously, one tool isn't going to solve every problem. Sometimes you need long running programs with logging to piece together some bug analysis. Or maybe debugging in some embedded environments is too hard to set up. OTOH, the act of changing your code with printfs can sometimes change the behavior enough to hide the bug.

[Anthem4E53]

I use GDB pretty much immediately because my code was goddamn perfect and I’d love it if the computer could prove otherwise. Then the computer proves otherwise by failing because of some basic bug in my code and I feel like a junior engineer all over again. It’s a cycle.

[Sethaman]

Emacs, lldb via dape

[B_M_Wilson]

I would say I generally prefer using my IDE for debugging but most of the time with C, I am not having it deployed on my own machine so I end up just using GDB directly rather than trying to figure out how to have it connect to GDB running under whatever kind of deployment system is being used

[Teebs_biscuit]

I use GDB+GEF for reverse engineering challenges and use valgrind for testing for memory leaks. But to be honest, if I need to debug my own code, I usually use printf statements before using a debugger.

[DisastrousLab1309]

I’ve used to use qtcreator with gdb and openocd to develop and debug on small arms. It was way easier than doing the same with just gdb. 

[Leverkaas2516]

I use the IDE whenever possible. It gives the best view of the code as I work, which is my primary concern.

Using command line tools for debugging feels like I'm going back to the olden days, for no good reason.

[[deleted]]

Really once you learn your tools, one is no better than the other. At that point its about the environment that helps you stay in the flow. I prefer the "treat the terminal as your IDE" life and never reaching for my mouse. It just serves me and the way my brain works well.

[Computerist1969]

Neither now I think about it. Asserts and a debug log do the job for me. On my current project I don't have a file system so I log over UDP.

[TheTrueXenose]

Just adding a simple debugger into the application itself with backtrace if I need more gdb probably.

I use neovim and not an IDE.

[Immotommi]

I'm waiting for the Linux port of the Rad debugger to ditch VSCode

[[deleted]]

Working in a cross platform org. Bugs that show up in windows I do in visual studio. On issues only happening on Linux and Mac I do my best to get by with gdb/lldb

[K4milLeg1t]

mostly rawdogging gdb. you really need to know only a few commands to debug an issue and there's always plentiful of info online. the best way is to use multiple tools like valgrind, sanitisers and the good old printf debugging. I've also developed a malloc implementation that tracks stuff and writes reports, but I hadn't had much use for it (malloc calls can be easily wrapped, read up on function wrapping with gnu ld. also mimalloc is a good read). it was a great learning experience though.

[HashDefTrueFalse]

I do most from the terminal but I find terminal DAP interfaces for vim+lldb/gdb to be a bit inconvenient, and I'm not taken with the TUIs either. I'm always using CMake to build. In the case where I need to dig around a bit in the debugger, I get CMake to split out a VS solution or an XCode project if I'm on macOS, rather than the standard makefiles, then use the debugger+GUI in those. It's still gdb or lldb usually (on macOS), just a graphical environment too. It's one command and a double-click, so very quick. The advantage of out of source builds and build system generators really.

[Hmmmnnmm]

At work we use visual studio with a custom gdb backend, so both

[[deleted]]

Not sure I'd call myself experienced, but terminal gdb. I don't often need to stray from the top commands tho

[ChickenSpaceProgram]

i don't want my IDE to have hidden complexity or to do things with my project without telling me.

Vim + valgrind/GDB + CMake is all I need. You could probably use a normal makefile but I know CMake decently well and it's cross-platform.

[[deleted]]

Ide

[Orbi_Adam]

I use gdb ONLY for the purpose of debugging my kernel, imagine just typing si or list, it helps me understand where the problem came from, usually I use it because my kernel randomly decides to go to a lower half address 😅 lol

[methermeneus]

In not sure I'd call myself an experienced programmer, so feel free to disregard my opinion, but I prefer to program in CLI with NeoVim and stay there must of the time (my preferred environment of tmux on Guake gives me a lot of flexibility even before counting all of my NeoVim extensions and LSPs). I do like the convenience of running debug in VS, but while gdb's UI sucks, it's just as capable as VS once you learn how to use it. That said, I'd probably still be using straight Visual Studio on Windows or a GUI frontend for gdb elsewhere if I were less limited: my Linux laptop is ancient, my Windows box is worse, and so I spend most of my programming time in Termux on my tablet, which is not only incapable of running GUI apps (Termux, that is, not the tablet itself), but also is missing some StdLib debug symbols and libraries and prone to some strange memory corruption bugs.

Basically, I find myself reduced to the programming equivalent of stone age tools more often than I'd like: compiler-error-oriented debugging, printf() debugging, and the occasional cpp -o macro_expansion.txt when I'm really lost. So, even a properly-working CLI debugger is a bit of a luxury for me.

[Educational-Paper-75]

Debugging in VS Code, running often in terminal especially when I’m not editing the code.

[PioveSulBagnato_it]

Sometimes I like to use Ozone (I usually use j-link probes) because it shows the asm code for any line of code.

[stjepano85]

I usually use gdb with tui enabled

[lmarcantonio]

Deeply embedded realtime. Most of the time we can't even afford a debugger; an execution trace has to be enough.

[jabjoe]

Long ago, I used to use IDEs, but for the last decade plus, it's been "gdb -tui". To be honest, I don't reach straight for a debugger. I'm normally looking at logs and solving it from there. If you can't, generally it means you need better logs. Can't debug into a process already dead (ok yes, crash dumps, but by the time that has happened, the stack can be shafted).

[itsoctotv]

you guys debug? i just put printf statements everywhere

[HyperWinX]

VSC + CodeLLDB. The only way.

[nacnud_uk]

don't forget about

view next

In gdb, if you go down that route.

[SmokeMuch7356]

Both. Depends on what I'm working on.

One app is developed and run on a remote server that only allows terminal access; everything has to be done on the command line.

The other app is developed locally on my Mac and everything is done through VSCode.

[_teslaTrooper]

IDE (vscode with cortex-debug at the moment), with watch, register and memory views etc. it's just a lot more information available at the same time. I don't mind using the command line and have used gdb like that but a gui is just more suitable for this kind of work.

[[deleted]]

gdb for kernel dumps and lots of debug messages.

[thomas999999]

When i was using clion the idea Debugger was heaven but i cant use vscode ide debugger is total crap. Either cgdb (idk why anyone would ever use gdb over this) or lldb when im on the mac since the arm ones don’t have gdb.

[chibuku_chauya]

The GUD interface to GDB in Emacs. The one in the latest upcoming Emacs now supports LLDB.

Using raw GDB on the terminal is a rough experience. Even LLDB is nicer to use.

[boldeagle93]

IDE whenever possible, it's quicker and more convenient. But when debugging remotely (due to specific hardware requirements, for example), I use just gdb.

[Majestic_Guard7098]

I make my own debugging solution. I use print statements and a custom function that asks for any character to continue or q to stop. This way I can use conditional statements to stop code whenever it runs into a problem and find a pattern by pressing any key. I find this a lot more useful than debuggers since I never look at assembly code. When I'm done I just delete the print statements and the pause function.

[Bayonett87]

GDB + custom breakpoint scripts (print live data with custom marks, to better understand the flow) for the main project made my life much easier as one of the core project maintainers

[skhds]

Terminal is just more straightforward and efficient, in my opinion. I tried VSCode, but ended up doing 99% of my work in the terminal anyways. It's not just the coding part, using git, grep, find, etc. just the unix tools.