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

GDB 8.1 Released

sourceware.org

Post reply on HN
Print view View original

41–50 of 62 posts

Re: GDB 8.1 Released

#41

Post by jcelerier »

dustfinger wrote: post #21
modeless wrote: post #20

Earlier quoted context omitted.

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.

> 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.

Re: GDB 8.1 Released

#42

Post by tonyg »

lucb1e wrote: post #6
dmm wrote: post #4

Earlier quoted context omitted.

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.

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...

Re: GDB 8.1 Released

#43

Post by jburgess777 »

kazinator wrote: post #13

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…

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...

Re: GDB 8.1 Released

#44

Post by jhasse »

zython wrote: post #5

> 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

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

Re: GDB 8.1 Released

#45

Post by kazinator »

jburgess777 wrote: post #43
kazinator wrote: post #13

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…

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 "semihos…

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.

Re: GDB 8.1 Released

#46

Post by kazinator »

monocasa wrote: post #33
kazinator wrote: post #13

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…

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.

Re: GDB 8.1 Released

#47

Post by flukus »

jhasse wrote: post #44
zython wrote: post #5

> 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

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.

Re: GDB 8.1 Released

#48

Post by [deleted] »

jhasse wrote: post #44
zython wrote: post #5

> 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

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

[deleted]

Re: GDB 8.1 Released

#49

Post by monocasa »

kazinator wrote: post #46
monocasa wrote: post #33

Earlier quoted context omitted.

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/l…

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.

Re: GDB 8.1 Released

#50

Post by rurban »

ebeip90 wrote: post #40
xuhu wrote: post #15

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.
Post reply on HN