When programming assembly (or any language really) I typically use vim however, I'm not apt to debugging because of all the either unstable or resource consuming debuggers. I'm currently using Visual Studio for debugging most my assembly files but as a multi-tasker as many of us are I have many files, programs, etc. open/running, loading up and using Visual Studio seems a task on it's own because of it's resource intensity especially for assembly, it's overkill.
For this reason I'm looking for a new debugger for MASM
It needs to be:
- Stable
- Minimal
- Preferably a CLI/TUI
- Native to Windows
Any suggestions would be greatly appreciated.
Olly is still the best for 32-bit code. See also Integrated debugging.
(Apr 10, 2017 03:09 AM)Masm4ever Wrote: Olly is still the best for 32-bit code. See also Integrated debugging.
Taking a look at Olly now, I'll post back with an update.
Thank you for the suggestion.
(Apr 10, 2017 03:09 AM)Masm4ever Wrote: Olly is still the best for 32-bit code. See also Integrated debugging.
Using olly for both MASM and FASM for a few days, works seamlessly with both, I applaud you for the recommendation. 🤝
Yeah olly is awesome for 32 bit.
There's also IDA pro if you can get it. But in some ways olly is easier than better than IDA.
Apr 23, 2017 06:50 AM
(This post was last modified: Apr 23, 2017 07:38 AM by Uefi.)
(Apr 22, 2017 07:20 PM)PhargedPhreak Wrote: Yeah olly is awesome for 32 bit.
There's also IDA pro if you can get it. But in some ways olly is easier than better than IDA.
IDA is very resource intensive so I tend to limit it's usage to RE only, using solely as a debugger is simply inefficient.
xdbg64 seems OK.
I gotta be honest though, I prefer IDA pro plus windbg even though it's slow.
May 6, 2017 02:07 PM
(This post was last modified: May 6, 2017 02:12 PM by Irritiable.)
(Apr 23, 2017 06:50 AM)Uefi Wrote: IDA is very resource intensive so I tend to limit it's usage to RE only, using solely as a debugger is simply inefficient.
Not trying to be rude, but: "Resource intensive?" 2017...
DDR3 RAM is a dime a dozen.
CPUs are nearly 4GHz+ depending on type (cheap too).
GPUs take heaps off loads.
HDDs (7,200 RPM) or SSDs are, again, cheap as a pancake.
What sort of performance hit does software from the '90s (2005) take on your machine? 0.03s?
X64dbg best. End of discussion :)
(May 6, 2017 02:08 PM)eskimo1 Wrote: X64dbg best. End of discussion :)
Start of discussion: It's a bad imitation of OllyDbg. Overloaded with crappy features, and it crashes too often for my taste.
DO NOT DEAL WITH THIS MEMBER
May 6, 2017 06:23 PM
(This post was last modified: May 6, 2017 07:00 PM by g4143.)
(May 6, 2017 02:07 PM)Irritiable Wrote: Not trying to be rude, but: "Resource intensive?" 2017...
DDR3 RAM is a dime a dozen.
CPUs are nearly 4GHz+ depending on type (cheap too).
GPUs take heaps off loads.
HDDs (7,200 RPM) or SSDs are, again, cheap as a pancake.
What sort of performance hit does software from the '90s (2005) take on your machine? 0.03s?
Its a known fact that its generally cheaper to throw hardware at a bottleneck than get a programmer to code their way around that bottleneck. Basically desktop/laptop/hand held hardware is dirt cheap.
(May 6, 2017 02:07 PM)Irritiable Wrote: Not trying to be rude, but: "Resource intensive?" 2017...
DDR3 RAM is a dime a dozen.
CPUs are nearly 4GHz+ depending on type (cheap too).
GPUs take heaps off loads.
HDDs (7,200 RPM) or SSDs are, again, cheap as a pancake.
What sort of performance hit does software from the '90s (2005) take on your machine? 0.03s?
Software from 2005? Visual Studios had an update this year hence why it's called Visual Studio 2017. I develop in a virtual machine as well, I have multiple VMs going simultaneously limiting each to 1-2 private cores.
(May 7, 2017 05:57 AM)Uefi Wrote: Visual Studios had an update this year hence why it's called Visual Studio 2017.
And Visual Crap is the best proof that we urgently need more assembler programmers. It is so incredibly slow that I avoid it like the plague.
(May 6, 2017 05:45 PM)Masm4ever Wrote: Start of discussion: It's a bad imitation of OllyDbg. Overloaded with crappy features, and it crashes too often for my taste.
I'm sure the dev team of x64dbg would love to hear feedback about your crashes rather than see people like this bitch that 'it sucks' or 'it crashes' and never give any feedback to the actual developers to fix any said issues. Can't say I have the same experience with it though. The primary goal of x64dbg was to make an Olly-like debugger for 64bit since Olly does not support it. The 32bit debugger they include is just an added bonus.
Personally, I prefer it over Olly these days depending on the target since it is much more stable than Olly and has an actual active development team, unlike Olly which has been 'dead' for a few years now and more or less relies on community plugins/patches to fix any issues that happen with it.
May 8, 2017 02:32 AM
(This post was last modified: May 8, 2017 02:36 AM by Uefi.)
(May 7, 2017 06:32 PM)atom0s Wrote: I'm sure the dev team of x64dbg would love to hear feedback about your crashes rather than see people like this bitch that 'it sucks' or 'it crashes' and never give any feedback to the actual developers to fix any said issues. Can't say I have the same experience with it though. The primary goal of x64dbg was to make an Olly-like debugger for 64bit since Olly does not support it. The 32bit debugger they include is just an added bonus.
Personally, I prefer it over Olly these days depending on the target since it is much more stable than Olly and has an actual active development team, unlike Olly which has been 'dead' for a few years now and more or less relies on community plugins/patches to fix any issues that happen with it.
I'd love to see a response to this, currently using x64dbg for RAX stepping.
(May 7, 2017 01:31 PM)Masm4ever Wrote: And Visual Crap is the best proof that we urgently need more assembler programmers. It is so incredibly slow that I avoid it like the plague.
Visual Studio alone takes 8GB in storage, it's simply too massive to be utilised for asm development and debugging.
|
![[Image: SHZzU7.gif]](https://#/SHZzU7.gif)
