3 ms·

I haven't seen anyone demonstrate using gdb via CLI in the way you can show off using vim proficiently and have people say "I get it". In the reverse engineeri

by 2c2c2c 5y ago

I haven't seen anyone demonstrate using gdb via CLI in the way you can show off using vim proficiently and have people say "I get it". In the reverse engineering space there's some folks that use gef. but maybe that's because linux folks dont have olydbg? would love to see a livestream of someone using gdb in the context of real world engineering. SHOW me the productivity wins here. every article and conference talk about gdb is just handwavey hypotheticals about what you could do, but in practice I just see people moving through basic debugging incredibly slowly

nomel 5y ago
> but in practice I just see people moving through basic debugging incredibly slowly What are you comparing this to? A person skilled with an IDE?
- 2c2c2c 5y ago
  single video of someone starting, stopping, and setting breakpoints across hundred+ file programs or during a regular debug task please
- worthless-trash 5y ago
  There are no goal-posts that are both sides will find acceptable in these discussions. As a general rule i have found it almost impossible to 'change' someones mind, you can influence an undecided person, but changing someones mind is generally a waste of time. Unless you have financial incentive to do this, you're going to be running this at a loss, let the 'fixed mind' party take the hit of being wrong.
disconnect3d 5y ago
As a CLI power user I can say that I don't think CLI gives much productivity wins over UI/IDE debugging. However, it lets you script things, display things that your IDE wouldn't normally display for you and do some automatic or semi-automatic analysis. Also, as you said indeed there is no ollydbg, or rather x64-dbg equivalent on Linux (which is what people use nowadays on Windows as ollydbg is not developed anymore afaik). Also even if you use GDB in IDE, you still may need to fall back to the embedded GDB console as e.g. some classes are missing pretty printers or the IDE UI does not allow you to investigate navigate things properly. For example when you have a structure field that is void* and is casted to one or another type depending on the context, it is much easier to use the console to investigate it.

by 2c2c2c 5y ago

nomel 5y ago

> but in practice I just see people moving through basic debugging incredibly slowly What are you comparing this to? A person skilled with an IDE?

2c2c2c 5y ago
single video of someone starting, stopping, and setting breakpoints across hundred+ file programs or during a regular debug task please
worthless-trash 5y ago
There are no goal-posts that are both sides will find acceptable in these discussions. As a general rule i have found it almost impossible to 'change' someones mind, you can influence an undecided person, but changing someones mind is generally a waste of time. Unless you have financial incentive to do this, you're going to be running this at a loss, let the 'fixed mind' party take the hit of being wrong.

disconnect3d 5y ago

As a CLI power user I can say that I don't think CLI gives much productivity wins over UI/IDE debugging. However, it lets you script things, display things that your IDE wouldn't normally display for you and do some automatic or semi-automatic analysis. Also, as you said indeed there is no ollydbg, or rather x64-dbg equivalent on Linux (which is what people use nowadays on Windows as ollydbg is not developed anymore afaik). Also even if you use GDB in IDE, you still may need to fall back to the embedded GDB console as e.g. some classes are missing pretty printers or the IDE UI does not allow you to investigate navigate things properly. For example when you have a structure field that is void* and is casted to one or another type depending on the context, it is much easier to use the console to investigate it.