4 ms·

GDB loses significant functionality when debugging binaries that lack debugging symbols IMHO from experience with other debuggers, GDB is actually hostile to d

GDB loses significant functionality when debugging binaries that lack debugging symbols IMHO from experience with other debuggers, GDB is actually hostile to debugging at the Asm level, due to many perplexing design choices which may or may not be deliberate. Things like needing to add a superfluous asterisk when breakpointing on an address, the "disassemble" command not being able to do what it says and instead complaining about a lack of functions, etc.

kuroguro 2y ago
+1 there are many pain points, probably for historic reasons. *nix almost always comes with the source, so binary only debugging is never a priority.
- pjmlp 2y ago
  True up to UNIX V6, and the FOSS clones, not so much for all big iron UNIXes.
jchw 2y ago
I have definitely gotten to the point of "Fine, I'll just use IDA Pro then". Of course, visual debuggers are another story entirely, but I'm not really thrilled with them either. For example I don't recall there being a good way to say "Decode the address at rax as a WNDCLASSA" or something like that in IDA. (I'm crossing my fingers for a Cunningham's Law here.)
- orisho 2y ago
  I don't recall what it was called in the menu, but it was definitely possible to assume a struct on a particular address. Muscle memory tells me the button is U, even though actual memory fails me.
- SoothingSorbet 2y ago
  You can jump to the address and then declare the data as a struct. It is annoying though that you can't make the register display show a particular type, it only shows unsigned hex integers. If I'm tracking a 32-bit float it is very frustrating, it won't even show you alternate representations on hover... For as good and expensive as IDA is, the UX sure is lacking.
  - jchw 2y ago
    Man, I can not believe it never occurred to me to do that. It's certainly what I would do when using IDA outside of debugging, but I guess it's just hard to internalize that you can do all of the same things to live memory in the debugger.
TuxSH 2y ago
> the "disassemble" command not being able to do what it says and instead complaining about a lack of functions, etc. For reference (for other readers), while I totally agree with you, disassembling at a particular address can be done via something like "x/20i $pc" ("display 20 instructions starting from content at $pc"). Something quite annoying as well is that you have to patch GDB in order to be able to use software single-step on custom OS/baremetal targets (IDA has no such issue, it is an option in their UI). GDB doesn't even honor their own remote stub protocol.
DannyBee 2y ago
They were deliberate. I added support for a lot of DWARF2 way back in the dark ages of time, and hit most of these design choices. It was basically built to support STABS (or was it DBX, i always forget). Everything else was an afterthought. That doesn't make it the wrong choice mind you, and lots of things have been made better or redesigned in the past 2 decades. But to your point, it wasn't really meant for the use case of assembly debugging. In part because assembly debuggers already existed on most OSen. Also, because if you were using GDB, you were supposed to have both the source, and the debug info (because it was the FSF debugger)

kuroguro 2y ago

+1 there are many pain points, probably for historic reasons. *nix almost always comes with the source, so binary only debugging is never a priority.

pjmlp 2y ago
True up to UNIX V6, and the FOSS clones, not so much for all big iron UNIXes.

jchw 2y ago

I have definitely gotten to the point of "Fine, I'll just use IDA Pro then". Of course, visual debuggers are another story entirely, but I'm not really thrilled with them either. For example I don't recall there being a good way to say "Decode the address at rax as a WNDCLASSA" or something like that in IDA. (I'm crossing my fingers for a Cunningham's Law here.)

orisho 2y ago
I don't recall what it was called in the menu, but it was definitely possible to assume a struct on a particular address. Muscle memory tells me the button is U, even though actual memory fails me.
SoothingSorbet 2y ago
You can jump to the address and then declare the data as a struct. It is annoying though that you can't make the register display show a particular type, it only shows unsigned hex integers. If I'm tracking a 32-bit float it is very frustrating, it won't even show you alternate representations on hover... For as good and expensive as IDA is, the UX sure is lacking.
- jchw 2y ago
  Man, I can not believe it never occurred to me to do that. It's certainly what I would do when using IDA outside of debugging, but I guess it's just hard to internalize that you can do all of the same things to live memory in the debugger.

TuxSH 2y ago

> the "disassemble" command not being able to do what it says and instead complaining about a lack of functions, etc. For reference (for other readers), while I totally agree with you, disassembling at a particular address can be done via something like "x/20i $pc" ("display 20 instructions starting from content at $pc"). Something quite annoying as well is that you have to patch GDB in order to be able to use software single-step on custom OS/baremetal targets (IDA has no such issue, it is an option in their UI). GDB doesn't even honor their own remote stub protocol.

DannyBee 2y ago

They were deliberate. I added support for a lot of DWARF2 way back in the dark ages of time, and hit most of these design choices. It was basically built to support STABS (or was it DBX, i always forget). Everything else was an afterthought. That doesn't make it the wrong choice mind you, and lots of things have been made better or redesigned in the past 2 decades. But to your point, it wasn't really meant for the use case of assembly debugging. In part because assembly debuggers already existed on most OSen. Also, because if you were using GDB, you were supposed to have both the source, and the debug info (because it was the FSF debugger)