GDB 8.1 Released | Hacker News Reader

GDB 8.1 Released

sourceware.org

99 pointsedelsohn59 comments

> New shortcuts for TUI Single-Key mode: 'i' for stepi, and 'o' for nexti;

TUI really is one of the best features to really get into gdb. visually stepping through the disassembly really makes debugging more appealing, I really wish they dont abandon this aspect of gdb

Try cgdb.

Since I was curious enough to look it up: https://cgdb.github.io/

My favorite visual gdb interface is the one build into emacs esspecially with gbd-many-mode

GDB developers use it extensively, so it's not going to disappear anytime soon. Of course it's far from perfect and there are better visual interfaces for GDB, but the fact that it's a keystroke away is its strong point.

Seems like a I cannot edit my post, but I just remembered this brilliant short talk (15min) about gdb's TUI.

https://www.youtube.com/watch?v=PorfLSr3DDI

It really did change my opinion of gdb in just 15 min.

Why not use a real GUI frontend like Visual Studio Code instead?

Can you use VSCode as just a debugger? IDE's typically require sacrifices like letting the IDE take over your build process.

Yes :) Install the Native Debug extension and then configure the debugger in the launch.json file.

Yep! This is all of the configuration needed to use VSCode as a debugger for Ocaml:

https://i.imgur.com/kY6NuXC.jpg

starti, rbreak and ptype sound good even if they've been available as idioms before.

starti did not exist before, and specifically addresses a StackOverflow question of mine from ~3 years ago: https://reverseengineering.stackexchange.com/questions/8724

ptype already existed, but did not print out offsets. This is incredibly useful, and something Windbg does with dt. Pwndbg does this in GDB by adding new commands.

Does this mean p does not work anymore, because there are now 2 commands starting with p? This would be a shame.

I checked it out. p still works as before.

But I needed a C++ patch on osx with cc/clang. Apparently they added cxx files with the .c extension: gdb/probe.c:63

    - const any_static_probe_ops any_static_probe_ops;
    + any_static_probe_ops any_static_probe_ops;

Presumably the stackexchange answer is what OP meant by it being an idiom.

I'd really like a way for a program to have an API for interacting with GDB: with that it could tell "I'm running under a debugger". There would be a file descriptor which talks to the debugger, if the debugger is present. Output sent to it goes to the debugger and perhaps it could obtain input from the debugger also. Maybe the API could provide some introspection: the program could ask what breakpoints have been set and things like that.

this is not particularly hard to do with the Python interface: you define structures that are known by the process and the Python module + global variables, then you set an internal (silent) breakpoint on a given 'event' function. In the program you fill the structure with some queries, and in the Python breakpoint callback, you process it as you need. This is the way multi-thread debugging work (used to at least), shared library detection as well...

Okay, good ideas there: so the program has some standard dispatch function that can be called to talk to the debugger. Normally that does nothing. The debugger can recognize this function and stick a breakpoint in it to alter the behavior.

The function can do something like put a request into a mailbox buffer, and then check for a reply in the inbox buffer. When there is no debugger, there is never any reply.

When the debugger stops the show with the breakpoint, it processes the request and prepares a reply, flipping some "reply present" flag; when the program is resumed then, it gets the reply.

It would be good not have any of that damned Python monkey business involved in this.

> It would be good not have any of that damned Python monkey business involved in this.

please, GDB internals are open source, you can do all of that in plain C :D That's what I did initially, to give GDB the ability to distinguish user-level threads (see libthread_db).

Having a high-level language / interface to GDB is a great again of time !

Having the program behave differently under a debugger is a great way to introduce bugs that disappear when the debugger is present. Any features of this type would have to be completely optional.

Yes, and introducing bugs is not the only issue at stake.

Imagine malware that could react differently when a debugger is attached.

The debugger could have a mode of "stealth attachment" under which that feature is not activated; the connection with that special interface is not made, and so the program is not informed that it's under a debugger, and those debug streams don't connect to anything.

Malware already does this. Non-malware programs already do this to complicate analysis.

If those non-malware programs are fixed to use a proper API instead of side channel hacks, then it simplifies analysis.

> If those non-malware programs are fixed to use a proper API instead of side channel hacks, then it simplifies analysis.

I think you’re missing the point as to why programs would do this. Usually it’s to protect some sort of DRM scheme through obscurity.

Malware already does this on many platforms via many methods, and has done so for perhaps decades.

Here's [1] the tip of the iceberg on this issue.

[1] antukh.com/blog/2015/01/19/malware-techniques-cheat-sheet/

Well, to be fair malware already exists that can detect when a system debugger is attached so maybe my concern is invalid. I guess the greater concern is the introduction of bugs after all.

Edit - Other commenters beet me to this point :-P

The program is what it is and it has bugs. There is a risk that bugs are irreproducible under a debugger (no matter how transparent the debugger). Oh well; you have to debug those in some other way. That risk shouldn't paralyze us from innovating debuggers.

There are bugs that won't reproduce when you debug via JTAG; so what.

Simply pausing on a breakpoint can make a bug irreproducible.

Programs can infer that they are being debugged via timings, and various side channels.

The issue is that by introducing this feature, you're increasing the number of programs that behave differently when a debugger is attached. Just because this can be an issue today doesn't mean that we should make it even more of an issue tomorrow.

> Imagine malware that could react differently when a debugger is attached.

that has been the case for a long time: simply timing some instructions is generally enough to tell you that you're running under a debugger. It's also helpful for copy protection.

Any optional features are a good way to have an application behave differently when the option is on, versus off. :)

Programs behave differently under a debugger anyway; "bugs disappearing under a debugger" already happens now.

It's just a question of the risk/reward.

"This debugger feature increases the scope of situations when a bug disappears under the debugger": that's a risk.

"This debugger feature gives me a better overall debugging experience most of the time": benefit

I'm a little unclear as to what your end goal is.

One use case would be to have some debug_printf() in the program that shows up in the debugger, no matter whether the debugger is remote or local. It doesn't go to some console, or file, but always to the debugger.

The Microsoft environment has something like this: OutputDebugString. Very useful.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

Also IsDebuggerPresent: https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

and other things.

The debugging experience on Windows 20+ years ago was was ahead of debugging on GNU/Linux today, I'm afraid, so this stuff is above criticism from the "M$ SuX" angle.

You don't need OutputDebugString on because you can always tap the write syscall on stdout from gdb.

And I don't really know what IsDebuggerPresent gets you.

You're really focusing on features, rather than use cases.

Well, stdout isn't a debug channel; you might want to debug a program that actually uses stdout for its output, not for debug chatter.

Never mind that though, we can take some other descriptor, like 3, and bind it to, say /dev/null.

What are the gdb commands to have whatever is going to file descriptor 3 be shown inside gdb?

I really do not care how it's implemented. However, "tightly integrated" is better than "flimsy hack"; "consumes breakpoints" is better than "doesn't consume breakpoints".

> Well, stdout isn't a debug channel; you might want to debug a program that actually uses stdout for its output, not for debug chatter.

What's your use case for this that makes stderr unsuitable?

stderr also isn't for debug output.

If, say, a compiler puts out "hello.c: syntax error" on its standard error stream, that is not a debugging diagnostic regarding that compiler's internals; it's about "hello.c".

stderr is not an instrumentation tool which goes away when we're not debugging the program.

Why? It's not like it'd be printing debugging level messages on release builds in either case.

Something like this is already supported by the GDB "remote" protocol:

https://sourceware.org/gdb/onlinedocs/gdb/Remote-Protocol.ht...

In your program you would probably need to link in some code to implement the protocol, like the GDB remote stub:

https://sourceware.org/gdb/onlinedocs/gdb/Remote-Stub.html

Qemu and Valgrind both implement their own gdb stubs.

For ARM targets, there is a similar feature named "semihosting":

http://www.keil.com/support/man/docs/armcc/armcc_pge13587870...

So that's a different approach: integrate a remote debugging GDB server into the program (could be a shared lib that is dlopen-ed, by the way). Then that server is always used, even in a local session. The server is deeply integrated into the program, taking advantage of the protocol to communicate between application code and the debugging client.

It sounds promising. A particularly interesting area is events:

https://sourceware.org/gdb/onlinedocs/gdb/Notification-Packe...

The program could generate custom notifications.

heh. Has anyone ever used gdb to debug Pascal? :)

I might have used it to debug Ada, which is like Pascal, back when I was in school.

I have to, on a regular basis actually and I'm glad gdb and FPC work well together.

Nice to hear, I have a pascal lisp project I need to revive, having gdb on my side would help

That's awesome! They taught Pascal in my CS undergrad classes.

Cool, but why are the release checksums in MD5?

I don't know, but they also have gpg .sig-files in the download folder.

MD5 is fine for verifying a download is not corrupted, so that's probably the intended use.

For that purpose, TCP already includes a CRC32. I'd say cryptographic hashes are generally meant for more than corrupted downloads.

Which is not that hard to fool on large files with multiple, sistemic errors.

File checksums are typically used when the checksum is still on the master site but the file could be in untrusted mirrors. TCP level stuff is useless in those scenarios.

So is md5

I have a machine which randomly zeroes blocks of 32 bytes in HTTP downloads [thought to be a cache-related fault] and TCP doesn't catch this.

TCP's checksum isn't even as good as CRC32. It's just a one's-complement sum of the packet and a few header words.

From this [0] helpful StackOverflow post:

> If you need to transfer data and you want to be sure the data didn't get corrupted, the TCP checksum alone is certainly not enough for this task. I would even dare to say that a CRC checksum is not enough for this task, since a CRC32 may not detect an error where more than 32 bits in a row are affected (these errors can "cancel out" each other). The minimum checksum you'd need for ensuring flawless data transfer is the MD5 value of the data.

[0] https://stackoverflow.com/questions/3830206/can-a-tcp-checks...

Ah yes, the standard nitpicky dismissive HN comment makes its appearance.

I’m quite amazed we’ve made it to 33 comments without somebody complaining it the project hasn’t been retooled with Rust/Clojure/Node.js yet.

There is no point on reimplementing GDB yet, you need first a legacy debugger with proper Rust support until the new one can debug itself.

Fair enough.

I had nothing interesting to say about the new GDB release, but the checksum used surprised me. Hence the question.

I see just a question, nothing "nitpicky dismissive" ? Has the comment been edited into a more neutral tone ?

Reply on news.ycombinator.com