Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GDB Frontend with C Pointer Visualization

github.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: GDB Frontend with C Pointer Visualization

#41

Post by BeeOnRope »

seanmcdirmid wrote: post #23
Razengan wrote: post #12

Earlier quoted context omitted.

"I don’t like this so nobody else should" is always obnoxious to read. I like dark mode. If it has options to let you have dark-text-on-bright-backgrounds, why does the option for a dark mode bother you? Tech should cater to different needs. Nobody should have to defend their preferences against anyone, but for those wondering if there are any objective reasons: I don’t want intense light constantly blasting my eyes,…

Unless you are using an OLED, a dark theme is not more energy efficient than a light one.

I don't think this is true: many transmissive LCD technologies adjust their backlight brightness, including differently across regions, depending on the displayed image?

Re: GDB Frontend with C Pointer Visualization

#42

Post by pjmlp »

kccqzy wrote: post #39
pjmlp wrote: post #3

Earlier quoted context omitted.

Or to go more into the past, a modern day Zortech C++ debugger. I still make use of DDD, one of the debuggers that made my UNIX development experience more enjoyable (vs PC/Mac tooling).

What prevents you from using DDD on a PC or Mac though? You may need to install an X server, but you should still be able to run it.

My point was that UNIX tooling did not match PC and Mac IDE based tooling and DDD helped to make it less painful.

Nowadays I focus on Apple, Microsoft, Oracle and Google platforms and languages, so DDD isn't something I miss.

Re: GDB Frontend with C Pointer Visualization

#43

Post by ebg13 »

jmiskovic wrote: post #15

I'm taking it for a spin and sharing my notes as I go: * UI has pleasant colors, I could get used to comfort of having all relevant info in side panes * The gdb starts in /opt/gdbfrontend directory, would be nice if it changed to dir you executed gdbfrontent in * I wish I could collapse Disassembly list - I don't want to see it ever * Icons don't have tooltips and some are not so clear * "Sources" pane doesn't actual…

It would be more pleasant to read your post if you didn't use code formatting. https://imgur.com/tYH8HWy

Re: GDB Frontend with C Pointer Visualization

#45

Post by monocasa »

lokedhs wrote: post #11
nathell wrote: post #2

This looks like a modern-day ddd [1]. Sorely needed. (Not much by me, since I don't do a lot of C these days, but I'd definitely use this if I did.) [1]: https://www.gnu.org/software/ddd/

That reminds me about that one day in at Sun back in the late 90's when I compiled Solaris in debug mode and set up KGDB. I was running a full Solaris kernel while anothe rmachine was running GDB and DDD. I was able to visualise all the kernel structures in realtime. It was significantly more usable that I would have imagined it to be. Can you do something similar these days with Linux?

Yeah, kgdb has been mainlined for a while.

In Windows land, windbg has supported this setup for forevers too.

Re: GDB Frontend with C Pointer Visualization

#46

Post by Doingmything123 »

With all of the improvements to static and run-time analysis that we see within compilers like -fsanitize, will it ever get to the point were tools like GDB become obsolete? It seems to me that as more work goes into this, it will become very hard for gdb/valgrind/... to compete with the full power/knowledge available to a compiler.

Re: GDB Frontend with C Pointer Visualization

#47

Post by seanmcdirmid »

BeeOnRope wrote: post #41
seanmcdirmid wrote: post #23

Earlier quoted context omitted.

Unless you are using an OLED, a dark theme is not more energy efficient than a light one.

I don't think this is true: many transmissive LCD technologies adjust their backlight brightness, including differently across regions, depending on the displayed image?

OLEDs incorporate the backlight with the pixel, so they can turn on or off the light for each pixel, giving you much nicer blacks. A typical LED backlight is just a single uniform light, so it can only be adjusted for the entire screen, and unless your screen is black, you need some light. I guess if everything was a at most a darker grey, they could crank it down, but I don’t think anyone does that?

Re: GDB Frontend with C Pointer Visualization

#48

Post by abhgh »

alexhutcheson wrote: post #40

For those who aren't aware, gdb has a curses-based 'Text User Interface' (TUI), which can be launched using 'gdb -tui': https://sourceware.org/gdb/current/onlinedocs/gdb/TUI.html#T... The interface is surprisingly good, and it's what I recommend to new gdb users if they aren't using an IDE. I still prefer the Emacs integration[1], but I don't recommend that to people who aren't already experienced Emacs users. [1] ht…

Seconding TUI. Pretty solid. In fact if you need a better debugger than that I see no reason as to not jump to a good IDE ... no other middle ground required.

Re: GDB Frontend with C Pointer Visualization

#49

Post by shmerl »

alexhutcheson wrote: post #40

For those who aren't aware, gdb has a curses-based 'Text User Interface' (TUI), which can be launched using 'gdb -tui': https://sourceware.org/gdb/current/onlinedocs/gdb/TUI.html#T... The interface is surprisingly good, and it's what I recommend to new gdb users if they aren't using an IDE. I still prefer the Emacs integration[1], but I don't recommend that to people who aren't already experienced Emacs users. [1] ht…

Is it better than cgdb? https://cgdb.github.io
Post reply on HN