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

21–30 of 62 posts

Re: GDB 8.1 Released

#21

Post by dustfinger »

modeless wrote: post #20
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…

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.

Re: GDB 8.1 Released

#23

Post by kazinator »

modeless wrote: post #20
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…

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.

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

Re: GDB 8.1 Released

#24

Post by kazinator »

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.

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.

Re: GDB 8.1 Released

#25

Post by stouset »

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.

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

Re: GDB 8.1 Released

#26

Post by ChrisLomont »

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.

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/

Re: GDB 8.1 Released

#27

Post by dustfinger »

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.

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

Re: GDB 8.1 Released

#28

Post by kazinator »

wazari972 wrote: post #16
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…

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), s…

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.

Re: GDB 8.1 Released

#29

Post by kazinator »

dustfinger wrote: post #27
dustfinger wrote: post #21

Earlier quoted context omitted.

Yes, and introducing bugs is not the only issue at stake. Imagine malware that could react differently when a debugger is attached.

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.

Re: GDB 8.1 Released

#30

Post by simark1 »

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

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