←back to thread

Seer: A GUI front end to GDB for Linux

(github.com)
376 points turrini | 8 comments | 15 Nov 24 12:36 UTC | HN request time: 1.025s | source | bottom
Show context
rkharsan64 ◴[15 Nov 24 13:44 UTC] No.42146864[source]▶
On a general note, I would recommend any new (and experienced!) programmers to master the debugging tools of their ecosystem. I've seen countless experienced developers use printf-based debugging and waste hourse debugging something which could've been easily figured out by setting a breakpoint and stepping through your code. This is also a good way to understand code you're unfamiliar with.

This is one area where I believe a GUI tool is so much better: I can hover over variable names to view their values, expand and collapse parts of a nested structure, edit values easily, and follow execution in the same environment I write my code in.

Sure, it doesn't help much for some scenarios (one I've heard people mention is multithreaded code, where logs are better?), but for most people it's not that far from a superpower.

replies(13): >>42147055 #>>42147066 #>>42147101 #>>42147176 #>>42147333 #>>42147405 #>>42147537 #>>42147789 #>>42147794 #>>42148121 #>>42148413 #>>42149115 #>>42152454 #
1. underdeserver ◴[15 Nov 24 14:08 UTC] No.42147066[source]▶
I would add to that that in most scenarios where people think debugging doesn't help or won't work - it can.

Running inside Docker, multithreaded, multiprocessed, all can be debugged with a little effort. Most often much less effort that repeatedly printf debugging.

replies(2): >>42147154 #>>42148173 #
2. cassepipe ◴[15 Nov 24 14:17 UTC] No.42147154[source]▶
I am not sure I understand your point. Can you be more explicit ?
replies(2): >>42147798 #>>42147805 #
3. shortrounddev2 ◴[15 Nov 24 15:33 UTC] No.42147798[source]▶
Many people believe that a debugger won't work in their specific scenario, but often they are wrong; debugger can connect across network boundaries or into other processes that weren't launched by the IDE
4. fisf ◴[15 Nov 24 15:33 UTC] No.42147805[source]▶
People who think that case X cannot be debugged without printf often don't know the features of their debugger. I.e. look at several of the comments which seem to miss that you can:

- Remote debug.

- Use conditional breakpoints.

- Use breakpoints to trigger commands, e.g. log values, enable other breakpoints, etc. instead of stopping. execution.

- Debug multi-threaded code.

- Disassemble a fragment.

replies(3): >>42147908 #>>42147921 #>>42149234 #
5. gregthelaw ◴[15 Nov 24 15:46 UTC] No.42147908{3}[source]▶
Just yesterday I gave a talk at MeetingC++ in Berlin on debugging multithreaded code. It's amazing how few developers know anything beyond the very basic of their debugger. If all you know is print, break, continue, next and then you dismiss the debugger as "not very useful" then you've not made a judgement based on information but on initial reaction.
6. gregthelaw ◴[15 Nov 24 15:47 UTC] No.42147921{3}[source]▶
I have a bunch of (36 if you're counting :) short videos and blog posts introducing the advanced features of GDB: https://undo.io/resources/gdb-watchpoint/
7. HumblyTossed ◴[15 Nov 24 16:10 UTC] No.42148173[source]▶
And a good debug log can help more than either of those.
8. cassepipe ◴[15 Nov 24 17:56 UTC] No.42149234{3}[source]▶
Oh thanks, I know about that and agree. I did not understand the point about doing debugging in containers.

But I think I understand now. I guess they only debugging a program that is running in a container.