When he's talking about in TUI being stuck in the source window you can switch windows using ctrl+o, this will allow up/down arrows again in the command window.
Debugging is incredibly useful, even when a lot of people insist that print statements are sufficient. This talk inspires me to not be too dependent on CLion for debugging.
Doesn't CLion itself uses GDB and integrates that into their GUI? tbh I could agree that knowing a thing or two about GDB is useful but even if you master it it's still going to be less efficient than having easy access to everything at the same time neatly presented to you in a GUI + all the keyboard shortcuts
@@Dwyriel I agree. But for learning purposes (and not on payroll) I found GDB more rewarding when I fix bugs in my code. Again, on payroll you absolutely should be using a powerful and intuitive GUI debugger. Also, sometimes GDB is the only tool you have available such as the case with micro controllers or remote shell (special case). But again, even in those cases, you can setup a GUI debugger and connect it to GDB (A recent example of mine is the Raspberry Pico, I debugged it with GDB but connected to that with VS Code to use it's simpler interface). That's the end of my blog :)
Seems like its overly complicated just for the sake of keeping everything in a text window... Thankfully Gdb Enhanced Functions (GEF) brings GDB back to the late eighties. OR, you could use visual and not deal with this clunker at all.
it seems those key combinations are come from emacs (at least emacs style), great for emacser xD i use gdb in emacs so im not worrying about the UI, but its really cool that u tells how to findout those segmentation fault bug and how to locate it, great video
Under Ubuntu 18.04, core dumped file didn't get written into the current directory. The simplest and fastest way to resolve this is to `ulimit -c unlimited` then run the binary file again, the core file will be there.
What a piece of crap debugger.... Where in the agile hamster wheel do you have a time for this thing? I need quickly set breakpoint, watches, see local variables and work with callstack not to use the Python or whatever else.
I didn't know GDB was that powerful. Thankfully I joined one of his sharing about Undo (His company's product for time travelling debug), so I remember his name. What a gems here! Thanks a lot for the content, and please keep up the good work.
you dont have to type ctl-x etc... you can also type "layout src" will show C code , layout asm (assembly) and layout split (both). They need to add the python interpreter to the arm-none-eabi-gdb build
Did the emacs commands get incorporated into gdb proper? I often used emacs and used these commands to put a line marker in code and split window into 2 for the gdb CL. This is cool!
started out good but then halfway in he just flies away on this debugging journey where he lost me half way through so left the video. It was mostly a "look what we can do" but not how you actually do it.
My personally experience is that older versions of GDB this was true, frequent segv's, but I find later versions to be pretty reliable. Screen gets a bit confused so you need to ^L, but otherwise solid. YMMV of course.
I just tried using the record command with a real application. The recording took so much CPU the inferior process was running many times slower. It ran for a couple minutes and I never saw the startup messages. It is a TCP server and the client timed out trying to connect. I have no idea how many instructions per seconds were actually being executed. I tried using hardware trace support but my Intel CPU does not support it. The hardware is a single board computer with 4th Gen Intel Core. Oh there are a dozen threads running.
I fail to see the appeal of gdb even after the talk. For simple programs, some sort of print statement always suffices and for more complicated projects, you'd probably be using an IDE anyway.
My experience with gdb with the tui or even integrated in linux IDEs (they crash or hang so often) was generally awful. I curse every time I need to use it.
It's absolutely awful. Half the time you can't reliably step over or out of functions, you can't inspect STL containers out of the box, and the stupid thing crashes on malformed commands (or was that LLDB?). And you're typing all the time instead of using single-key shortcuts to quickly dig through the run. And he's presenting this "TUI" like a breakthrough advance of some kind. Yeah, VS has that, and everything else, give it a try sometime.
With Visual Studio I can unfold it on two monitors (or more), so code window is on my main screen and stack, threads, etc. are on the second screen. Can i do it with gdb?
This is a user interface question. And as usual, Google is your friend. Just look for "GDB frontend", and you'll be buried in programs that purport to do what you want.
You just saved lives with your 15 mins. Thanks, it was awesome. Now I feel that I was wasting time on GUI based debuggers! Still... for huge projects, GUI based debuggers help better.
? He’s sorry that the information in the presentation is useless to Windows developers. Meaning they can go ahead and leave and attend some other talk.
Not quite sure, but I think what is meant there is that "compile with debug information" = -g and "optimization level 1" = -O do not interfere whith each other.
"Orthogonal" in this context means "can be used independently". The -g option of gcc enables debugging information; -O enables compiler optimizations. That is, you're not limited to debug builds (with debugging information and no optimization) and release builds (no debugging information, but optimized), you can also enable both -g and -O (optimized build with debugging information). So if a bug only occurs when optimizations are enabled, you can still have debugging info to track it down. (That said, optimized builds like to combine and reorder instructions, so in the source view you might see the "current statement" jump around wildly when stepping through the code.)
Agree. I started embedded coding on Linux + Qt-Creator. I have everything working, compiling and running on my ARM and AVR chips, but Debuging jsut does nto work. Just can't find any proper info on how to integrate GDB into Qt-Creator and be able to just Debug like in Visual Studio. If this is not possible, that this endeed is very stupid, starting/stopping servers on a remote target and the rest...
ahaha, look at print at 6:35! It can't even print properly! The worst piece of software I ever came across in my life. It's a program from 1970s in a modern world. They can't even program a proper UI for it.
Well, nothing changed in the following regard: I keep getting surprised by functionality built into standard tools I’ve been using for 2 decades - functionality I had no idea it existed all along. Great presentation! Cheers!
thanks your video, can you please tell me how do you know need set break point at _exit.c:32, how we can test if on our compute(such as how we can find such breakpoint as _exit.c:32?
May be am too late to start learning to debug using GDB. I have a doubt, what is the equivalent of break point set at 'b _exit.c:32' in C++ (presenter mentions that this is c api). Sorry it might be stupid to ask this basic. Thanks in advance.
I still think that GDB sucks pretty much. Every time I wanted gdb to do something, I was just lost, I was not able to do it, and eventually gave up. That doesn't mean gdb was not able to do it, it was just that gdb was too complicated and obscure that it was impossible to me to use it. Gdb is not useless, because QT creator as a debugger is quite good, it it just uses gdb. But extending the functionality, like adding a print functions for my own class, just impossible.
VS is like an iphone.. its sweet.. got everything you need.. but I rather a Harmon Kardon stereo, and some superior quality camera than have to use my iphone for my pics and music playing.
This seems pretty archaic compared to Visual Studio. Can't these Linux guys make a good IDE (i.e. editor, code manager, help system, debugger). The trace ability functionality is cool though.
+gast128 Definitely not wanting to start a flame war, just curious. How can you debug application, running on remote machine or embedded device with VisualStudio?
+Tsvetomir Dimitrov I do not know embedded devices, but remote debugging was supported with Visual Studio (through msvsmon). I actually used it in the past; quite handy.
+gast128 I think you misunderstand the idea. GDB is a debugger, VS is an IDE. There are a lot of decent IDEs for Linux (none of them is as complete as VS, but that's another topic) and they all use gdb for debugging. What the lecturer shows is an alternative approach to debugging, which is very convenient for specific usecases like remote debugging, embedded devices, etc.
+Tsvetomir Dimitrov There is the difference: Visual Studio is an IDE and a debugger. That is very useful. You can just click lines of code to add breakpoints; no need for loading source files (Visual Studio uses pdb's to match binaries with) and when you change your code (adding or removing parts) the breakpoint automatically moves with the original code line. From this video it doesn't seem that GDB has any of this. This is all pity, since a great IDE 9with help system and integrated debugger) and games is what keeps me on the Windows platform.
+gast128 You still compare apples and oranges here. Let's stick to the debugging for a while. Tell me how you will debug a distributed application running on multiple nodes with VisualStudio (or Eclipse, QtCreator, etc.)? You will attach to each instance with your IDE without losing sanity? :)
emacs, vim and gdb are just plain archaic. When you are debugging on something like unreal engine, ability to view a lot of source line, syntax highlighting, intellisense, ability to switch files quickly is just given. Looking at a source, and putting a breakpoint, quick watch, watch local variables, watch stack, threads, without almost no configuration is just given and the way it should be. Imagine trying to get this working with unix tools, you'll waste days trying to get a vim, emacs plugin working. Quickly you'll learn there is another plugin which is 'better'. Sorry it is just fragmented community. Doesn't work out of the box, wastes my time. I prefer VS. And if you saw gdb is debugger, VS is ide. I'd still prefer VS over gdb, in fact use it via VS. VS is the way and superior to debug, gdb is a debugger need to be used by machines not humans.
Linux operating system was made using tools like Emacs, Vim and Gdb yet it's a million times more complicated than what you can be doing in Unreal Engine. IDEs like Visual Studio are like training wheels on bicyles, they're good to get you started, but you get rid of them once you get good enough. If you can't do programming without an IDE spoon fedding you, you're still an amateur.
I think gatekeeping like that might be slightly overdramatic. Stroustrup himself hates Vim and Emacs and I'd hardly call him an amateur. There are even a number of kernel devs that use QtCreator and KDevelop (albeit QtCreator provides a direct GDB console which is why I use it). Certainly GDB is very powerful and worth learning, but for simple stuff, plenty of competent devs stick to the path of least resistance. (However, I can't understand how people can say VS is more powerful when you need to shell out thousands of dollars for Ultimate if you want to be able to step backwards. I wonder if WinDB supports it from the command line...)
> ability to view a lot of source line, syntax highlighting, intellisense, ability to switch files quickly You're aware that emacs already has all of those features right? And, even if it didn't you could add them yourself as it's completely programmable, unlike visual studio.
@@Ultr4noob And GDB can be use with VS.. But honestly I use VS now, I use to use GDB, but I find myself way more efficient and working way faster with VS. The profiler of VS is also really nice and really powerfull. Once you've set up your environnement correctly Visual studio became quite a powerfull tool, you can see as many information than with GDB. I originaly switch from GDB to VS because I had to code a DirectX application, but nowdays I'm still working in OpenGL with VS. There are downsides to VS, as there are downside with GDB.. But find the one that you're better with. As I said, I use to be a GDB enthusiast.. Then I had to work with VS, and now I can't go back.. I'm way faster, I had to learn a lot of shortcut, work my environnement, ... but I'm debugging things way faster than I was able to with GDB.
To be honest, there were WAY better GDB tutorials I've seen on youtube. This guy seems to be presenting just to have his name on the web. Because if he used GDB on a daily basis, he wouldn't be showing these.....
This is not a tutorial. He's just showing some of gdb's capabilities. I think the talk shouldn't have been only 15 minutes long though, it's not enough time to really show some interesting stuff.
He is showing cherry-picked highly-motivational features that naysayers against GDB might realize are solutions already there to their gripes and that their gripes were not as well founded as the naysayers against GDB might have presumed. ¶ That is a drastically different goal than a crawl-walk-run exhaustive comprehensive tutorial on step into, step out, step over, watch a variable, and so forth ad infinitum.
Wow. I've been using GDB for years and I never knew it could do all of this.
When he's talking about in TUI being stuck in the source window you can switch windows using ctrl+o, this will allow up/down arrows again in the command window.
That would be: Ctrl-x o
Thanks for the tip!
For so many years printf for me was more useful than gdb. This talk has changed everything.
Debugging is incredibly useful, even when a lot of people insist that print statements are sufficient. This talk inspires me to not be too dependent on CLion for debugging.
Why'd you be using a tool from 1970, when you got a 2022 tool that's much more intuitive and efficient to use?
Doesn't CLion itself uses GDB and integrates that into their GUI? tbh I could agree that knowing a thing or two about GDB is useful but even if you master it it's still going to be less efficient than having easy access to everything at the same time neatly presented to you in a GUI + all the keyboard shortcuts
@@Dwyriel I agree. But for learning purposes (and not on payroll) I found GDB more rewarding when I fix bugs in my code. Again, on payroll you absolutely should be using a powerful and intuitive GUI debugger. Also, sometimes GDB is the only tool you have available such as the case with micro controllers or remote shell (special case). But again, even in those cases, you can setup a GUI debugger and connect it to GDB (A recent example of mine is the Raspberry Pico, I debugged it with GDB but connected to that with VS Code to use it's simpler interface). That's the end of my blog :)
This was good, for some of us who cannot use IDE for coding and debugging. Wasn't aware of recording and reverse-continue. Thanks.
This quite annoying to follow when the first column is cut off by the screen-recording tool.
Finally a UA-cam title that delivers!
or ues Emacs with realgud (a gdb frontend):
github.com/realgud/realgud
If you’re going to use gdb, do yourself the favor and use the ‘cgdb’ tool/frontend vs this crappy TUI mode.
Thanks brah. very helpful.
very good, but sometimes you might not have access to something like that, for instance you might be ssh'ing to a server through console (real story)
I have a problem that on programs that do i/o, cgdb freezes after i/o. So I can't use that for those projects.
Seems like its overly complicated just for the sake of keeping everything in a text window...
Thankfully Gdb Enhanced Functions (GEF) brings GDB back to the late eighties. OR, you could use visual and not deal with this clunker at all.
it seems those key combinations are come from emacs (at least emacs style), great for emacser xD
i use gdb in emacs so im not worrying about the UI, but its really cool that u tells how to findout those segmentation fault bug and how to locate it, great video
Under Ubuntu 18.04, core dumped file didn't get written into the current directory. The simplest and fastest way to resolve this is to `ulimit -c unlimited` then run the binary file again, the core file will be there.
What a piece of crap debugger.... Where in the agile hamster wheel do you have a time for this thing?
I need quickly set breakpoint, watches, see local variables and work with callstack not to use the Python or whatever else.
Ctrl-p / Ctrl-n are common readline bindings.
When you discover all the power you had until now but didn't know that you can use !!!
I didn't know GDB was that powerful. Thankfully I joined one of his sharing about Undo (His company's product for time travelling debug), so I remember his name. What a gems here! Thanks a lot for the content, and please keep up the good work.
you dont have to type ctl-x etc... you can also type "layout src" will show C code , layout asm (assembly) and layout split (both).
They need to add the python interpreter to the arm-none-eabi-gdb build
Did the emacs commands get incorporated into gdb proper? I often used emacs and used these commands to put a line marker in code and split window into 2 for the gdb CL. This is cool!
started out good but then halfway in he just flies away on this debugging journey where he lost me half way through so left the video. It was mostly a "look what we can do" but not how you actually do it.
TUI mode is the buggiest part of GDB. It always crashes
My personally experience is that older versions of GDB this was true, frequent segv's, but I find later versions to be pretty reliable. Screen gets a bit confused so you need to ^L, but otherwise solid. YMMV of course.
We had a follow-up advertised, but on the channel, there's nothing after this about GDB until next year.
wonder why linux c++ programmers are superior to windows c++ programmers!!
Now give me my 15 minutes back
I just tried using the record command with a real application. The recording took so much CPU the inferior process was running many times slower. It ran for a couple minutes and I never saw the startup messages. It is a TCP server and the client timed out trying to connect. I have no idea how many instructions per seconds were actually being executed. I tried using hardware trace support but my Intel CPU does not support it. The hardware is a single board computer with 4th Gen Intel Core. Oh there are a dozen threads running.
To Windows developers "I'm sorry for you haha xd".
Two mins later: Opens up a debugger interface from the 80s *people applaud*
2:29 "CTRL + x, a" very nice trick, I like this video.
But it easily messes up my screen.
@@baiwfg2 Press Ctrl+l (l as in Lima) to refresh the screen
Reverse debugging is awesome, unless any avx instructions 😅
idk why i would ever use this over a visual debugger like in clion
simply give the command
layout src
to get the TUI
yes, I only learnt this a few months ago. That's the thing about GDB - there is always more to learn! :)
ctrl x + a beats me typing lay n 4 times!
I fail to see the appeal of gdb even after the talk. For simple programs, some sort of print statement always suffices and for more complicated projects, you'd probably be using an IDE anyway.
these tools are amazing. Its like there is a new debugging tool i never heard of inside gdb!
My experience with gdb with the tui or even integrated in linux IDEs (they crash or hang so often) was generally awful. I curse every time I need to use it.
It's absolutely awful. Half the time you can't reliably step over or out of functions, you can't inspect STL containers out of the box, and the stupid thing crashes on malformed commands (or was that LLDB?). And you're typing all the time instead of using single-key shortcuts to quickly dig through the run. And he's presenting this "TUI" like a breakthrough advance of some kind. Yeah, VS has that, and everything else, give it a try sometime.
@@apojoga Same here, I hate using gdb from the command line. The debugging experience in VS is just unmatched.
For me, who is used to Java and it's debugging via UI, c++ debugging and using gdb for that feels almost magical and I love it
Great video! Very useful!
Excellent Powerful presentation. Thanks.
Thank you for your comment!
I'm sorry Linux developers, you've to suffer the hell called gdb.
Greg ... We want more of that
Really useful stuff ! Thank you !
Glad it was helpful!
Glad it was helpful!
Thank you so much :)
You're welcome!
Isn't TUI part just layout next?
With Visual Studio I can unfold it on two monitors (or more), so code window is on my main screen and stack, threads, etc. are on the second screen. Can i do it with gdb?
This is a user interface question. And as usual, Google is your friend. Just look for "GDB frontend", and you'll be buried in programs that purport to do what you want.
You just saved lives with your 15 mins. Thanks, it was awesome.
Now I feel that I was wasting time on GUI based debuggers!
Still... for huge projects, GUI based debuggers help better.
they're always better.
He's sorry for Windows developers... Man, have you *used* the VS debugger?
?
He’s sorry that the information in the presentation is useless to Windows developers. Meaning they can go ahead and leave and attend some other talk.
Why not use cgdb?
What's the meaning of the last page of the slide: gcc's g and o is orthogonal?
Not quite sure, but I think what is meant there is that "compile with debug information" = -g and "optimization level 1" = -O do not interfere whith each other.
-O is for optimization, you should use -O0 to turn optimization off when building debug binary.
Ted Feng which is normally the default for gcc btw
"Orthogonal" in this context means "can be used independently". The -g option of gcc enables debugging information; -O enables compiler optimizations. That is, you're not limited to debug builds (with debugging information and no optimization) and release builds (no debugging information, but optimized), you can also enable both -g and -O (optimized build with debugging information). So if a bug only occurs when optimizations are enabled, you can still have debugging info to track it down. (That said, optimized builds like to combine and reorder instructions, so in the source view you might see the "current statement" jump around wildly when stepping through the code.)
Does anyone know an alternative C/C++ terminal debugger?
lldb - although I confess I've never actually used it. Also TotalView has a command line (as well as GUI).
@@greglaw9145 Thanks
Bad ass dude, thanks!
systemdeadlock
Ctrl-X A == eXtra Awesome
I am in love with gdb
Wow
awesome!!
Awesome - really good watch.
Last few minutes of this video are probably the most useful minutes of your time.
reverse debug I don‘t think vs debugger support that
what's that question at 5:07?
said the presenter didn't understand the keys cause he's a vim user
@@tohopes vim user here, that bit made me laugh out loud.
Shows up to hold a speech about GDB at CppCon, demonstrates it on pure C code... Smh
I genuinely don't understand what's the problem with you guys... Smh
I really wish I can block people on UA-cam
Agree. I started embedded coding on Linux + Qt-Creator. I have everything working, compiling and running on my ARM and AVR chips, but Debuging jsut does nto work. Just can't find any proper info on how to integrate GDB into Qt-Creator and be able to just Debug like in Visual Studio. If this is not possible, that this endeed is very stupid, starting/stopping servers on a remote target and the rest...
ahaha, look at print at 6:35! It can't even print properly! The worst piece of software I ever came across in my life. It's a program from 1970s in a modern world. They can't even program a proper UI for it.
Look like still can't disassemble to see how printf fully work....SADDDDDDDDD T-T
Nothing Changed
Sarcasm, yeah?
Well, nothing changed in the following regard: I keep getting surprised by functionality built into standard tools I’ve been using for 2 decades - functionality I had no idea it existed all along. Great presentation! Cheers!
thanks your video, can you please tell me how do you know need set break point at _exit.c:32, how we can test if on our compute(such as how we can find such breakpoint as _exit.c:32?
I get Undefined command: "record". this issue...
It's information about that gdb has no path with libc headers.
May be am too late to start learning to debug using GDB.
I have a doubt, what is the equivalent of break point set at 'b _exit.c:32' in C++ (presenter mentions that this is c api). Sorry it might be stupid to ask this basic. Thanks in advance.
In that particular case, "b exit" will get you a breakpoint whenever your program returns from main() or calls exit(), C or C++.
CRTL + X + 2 doesn't work
Use this instead : (gdb) layout split
hit ctrl-x first, let go of the keys, then press 2 by itself. In other words, ctrl-x 2 rather than ctrl-x-2
Ctrl X, and then press 2, like emacs
@@twerkingduck1275 thanks dude, I don't use emacs, was stuck there
I still think that GDB sucks pretty much. Every time I wanted gdb to do something, I was just lost, I was not able to do it, and eventually gave up. That doesn't mean gdb was not able to do it, it was just that gdb was too complicated and obscure that it was impossible to me to use it. Gdb is not useless, because QT creator as a debugger is quite good, it it just uses gdb. But extending the functionality, like adding a print functions for my own class, just impossible.
VS is like an iphone.. its sweet.. got everything you need.. but I rather a Harmon Kardon stereo, and some superior quality camera than have to use my iphone for my pics and music playing.
This seems pretty archaic compared to Visual Studio. Can't these Linux guys make a good IDE (i.e. editor, code manager, help system, debugger). The trace ability functionality is cool though.
+gast128 Definitely not wanting to start a flame war, just curious. How can you debug application, running on remote machine or embedded device with VisualStudio?
+Tsvetomir Dimitrov I do not know embedded devices, but remote debugging was supported with Visual Studio (through msvsmon). I actually used it in the past; quite handy.
+gast128 I think you misunderstand the idea. GDB is a debugger, VS is an IDE. There are a lot of decent IDEs for Linux (none of them is as complete as VS, but that's another topic) and they all use gdb for debugging. What the lecturer shows is an alternative approach to debugging, which is very convenient for specific usecases like remote debugging, embedded devices, etc.
+Tsvetomir Dimitrov There is the difference: Visual Studio is an IDE and a debugger. That is very useful. You can just click lines of code to add breakpoints; no need for loading source files (Visual Studio uses pdb's to match binaries with) and when you change your code (adding or removing parts) the breakpoint automatically moves with the original code line. From this video it doesn't seem that GDB has any of this. This is all pity, since a great IDE 9with help system and integrated debugger) and games is what keeps me on the Windows platform.
+gast128 You still compare apples and oranges here. Let's stick to the debugging for a while. Tell me how you will debug a distributed application running on multiple nodes with VisualStudio (or Eclipse, QtCreator, etc.)? You will attach to each instance with your IDE without losing sanity? :)
emacs, vim and gdb are just plain archaic. When you are debugging on something like unreal engine, ability to view a lot of source line, syntax highlighting, intellisense, ability to switch files quickly is just given.
Looking at a source, and putting a breakpoint, quick watch, watch local variables, watch stack, threads, without almost no configuration is just given and the way it should be.
Imagine trying to get this working with unix tools, you'll waste days trying to get a vim, emacs plugin working. Quickly you'll learn there is another plugin which is 'better'.
Sorry it is just fragmented community. Doesn't work out of the box, wastes my time. I prefer VS. And if you saw gdb is debugger, VS is ide. I'd still prefer VS over gdb, in fact use it via VS.
VS is the way and superior to debug, gdb is a debugger need to be used by machines not humans.
Linux operating system was made using tools like Emacs, Vim and Gdb yet it's a million times more complicated than what you can be doing in Unreal Engine. IDEs like Visual Studio are like training wheels on bicyles, they're good to get you started, but you get rid of them once you get good enough. If you can't do programming without an IDE spoon fedding you, you're still an amateur.
you must be using a calculator
I think gatekeeping like that might be slightly overdramatic. Stroustrup himself hates Vim and Emacs and I'd hardly call him an amateur. There are even a number of kernel devs that use QtCreator and KDevelop (albeit QtCreator provides a direct GDB console which is why I use it). Certainly GDB is very powerful and worth learning, but for simple stuff, plenty of competent devs stick to the path of least resistance. (However, I can't understand how people can say VS is more powerful when you need to shell out thousands of dollars for Ultimate if you want to be able to step backwards. I wonder if WinDB supports it from the command line...)
> ability to view a lot of source line, syntax highlighting, intellisense, ability to switch files quickly
You're aware that emacs already has all of those features right? And, even if it didn't you could add them yourself as it's completely programmable, unlike visual studio.
yeah and is slow as fuck too, to scroll a 5000 lines file. thank you
what a piece of shit compared to Visual Studio's debugger integrations. You can't ever claim to show a UI and diss on Windows at the same time.
rockgitmo visual studio is slow and buggy
>cpp se
>complains about UI
LMAO
Try debugging embedded devices with vs code, with all the power of gdb. Try
@@Ultr4noob And GDB can be use with VS.. But honestly I use VS now, I use to use GDB, but I find myself way more efficient and working way faster with VS. The profiler of VS is also really nice and really powerfull. Once you've set up your environnement correctly Visual studio became quite a powerfull tool, you can see as many information than with GDB. I originaly switch from GDB to VS because I had to code a DirectX application, but nowdays I'm still working in OpenGL with VS. There are downsides to VS, as there are downside with GDB.. But find the one that you're better with. As I said, I use to be a GDB enthusiast.. Then I had to work with VS, and now I can't go back.. I'm way faster, I had to learn a lot of shortcut, work my environnement, ... but I'm debugging things way faster than I was able to with GDB.
To be honest, there were WAY better GDB tutorials I've seen on youtube.
This guy seems to be presenting just to have his name on the web. Because if he used GDB on a daily basis, he wouldn't be showing these.....
Hi, I'm just learning to use GDB, can you post some links to other tutorials that you find useful?
This is not a tutorial. He's just showing some of gdb's capabilities. I think the talk shouldn't have been only 15 minutes long though, it's not enough time to really show some interesting stuff.
He is showing cherry-picked highly-motivational features that naysayers against GDB might realize are solutions already there to their gripes and that their gripes were not as well founded as the naysayers against GDB might have presumed.
¶ That is a drastically different goal than a crawl-walk-run exhaustive comprehensive tutorial on step into, step out, step over, watch a variable, and so forth ad infinitum.
Ever heard of a not so new tool called IDE?
You are welcome.
How do you work with IDEs when you are working from home over ssh?
Start a gdb/windbg server. Connect visual studio to it. Thank you boi
An IDE is a jack of all trades, master of none. You will never be a great programmer if you can't learn the best individual tools for your work.
Sure thing buster, keep wasting your time doing things the manual way.
these are the same people that think C++ headers should stay. Cause they are masochistic.