
GDB 8.1 Released - edelsohn
https://sourceware.org/ml/gdb/2018-01/msg00026.html
======
zython
> 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

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

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

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

[https://i.imgur.com/kY6NuXC.jpg](https://i.imgur.com/kY6NuXC.jpg)

------
xuhu
_starti, rbreak_ and _ptype_ sound good even if they've been available as
idioms before.

~~~
ebeip90
_starti_ did not exist before, and specifically addresses a StackOverflow
question of mine from ~3 years ago:
[https://reverseengineering.stackexchange.com/questions/8724](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.

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

~~~
rurban
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;

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

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

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

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

~~~
dustfinger
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

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

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

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

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

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

------
rom1v
Cool, but why are the release checksums in MD5?

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

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

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

