102 points mariuz | 8 comments | | HN request time: 0.818s | source | bottom
1. Faelian2 ◴[] No.42157085[source]
I don't use GDB a lot. But when I do, I generally use the pwndb extension. It's written for exploit development, but even for debugging a C program. It makes things a lot nicer.

https://pwndbg.re/

replies(1): >>42160246 #
2. ◴[] No.42159779[source]
3. Conscat ◴[] No.42160246[source]
I love pwndbg. I work at the level of writing syscalls often, and it's wonderful that pwndbg's disassembler pretty-prints the operands of syscalls write next to the actual instruction.
4. Conscat ◴[] No.42160282[source]
I used to be excited about printing data layouts the way DDD or Rizin do it, but lately I've been getting into GDB pretty printers. They aren't very difficult to write (once you grasp the basics of the GDB API and compiler debug info flags), and they're a very cheap way to make reasonably pleasant representations of data structures. Although "cheap" is not "free", like these sort of tools are.
5. nj5rq ◴[] No.42163940[source]
Debugging with GDB from Emacs is amazing; thanks to Nick Roberts and Dmitry Dzhus.
6. Asooka ◴[] No.42165920[source]
Meanwhile, pleasant debugging on Windows:

1. Open Visual Studio

But to be a bit less snarky, it's a real shame that projects in the Open-Source / GNU / Linux space can't build on past successes and keep rewriting things. Like, things are never well integrated and they can't settle to be well integrated because foundational technologies keep changing. As a simple example, if I had a Win32 binary that shows a dialogue window it would run and look native on every version of Windows, but if I had a Linux binary linked with GTK1 that shows a dialogue window, it may not even be possible to run and if it did, it would look incredibly ugly and out of place on a current distro. It's a problem that I really think is holding the whole ecosystem back - end-user programs are forced to constantly spend time to keep up with the churn of lower level components. Why doesn't e.g. GTK4 provide bindings for all previous major versions? Or OpenSSL? Or... etc. It's probably no coincidence that the most well-developed and powerful software for the platform is running in the terminal, based on tech that has remained fully backwards compatible for the last 40 years.

In that vein, I have always found it hilarious that the GNU C compiler has options for producing binaries targeting older versions of Apple's macOS, but has no such option for targeting older versions of GNU/Linux distros (at least let me pick the target GNU libc version!)

/rant

replies(1): >>42171770 #
7. Joker_vD ◴[] No.42171770[source]
> (at least let me pick the target GNU libc version!)

I've just resigned myself to build and run things in ubuntu:16.04/18.04/20.04/etc. containers. Surprisingly, modern Linux kernels support ancient Linux userspaces just fine. It's the Linux userspace that's incompatible with itself in both directions.