flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
okasvi
For user-mode debugging I suggest OllyDbg.
|
|||
![]() |
|
HyperVista
|
|||
![]() |
|
Garthower
I use FDBG. It's good and free debugger. I can find for more information at: http://board.flatassembler.net/topic.php?t=5045
|
|||
![]() |
|
ACP
Olly is great - especially if you use it's plugins and code analysis options - but it will only handle ring 3 code. For ring 0 use WinDBG:
http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx IDA Pro also has ring 3 debugger that supports Windows/Linux targets and remote debugging. When using WinDBG make sure you have symbol server properly configured. |
|||
![]() |
|
r22
Incremental developement is the best way to avoid having to debug stuff.
Make and test every procedure one at a time and if your code breaks you'll always know where to look (the last thing you didn't test). Of course there is always that case where you just can't find the problem and a debugger (OR massive amounts of printf/messagebox calls) is needed. Another good way to avoid spending hours in a debugger is use algorithms that you've already tested in a HLL (or even in other asm projects). You can throw something together pretty fast in say java or vb test it out make sure it works then write it in assembly and you'll have a good working base to start optimizing it. -off topic - does FDBG still go into the kernel APIs while debugging? I remember an old version I used for win xp64 did that and it was so annoying having to step through the windows apis to get back to my code. Maybe there was an option to turn it off but I was just ignorant of it. |
|||
![]() |
|
vid
Quote: Incremental developement is the best way to avoid having to debug stuff. r22: only in theory. You can't realize every possible state of function. Some functions can have 100 or more specific cases... impossible to find and try every one yourself. Quote: Another good way to avoid spending hours in a debugger is use algorithms that you've already tested in a HLL (or even in other asm projects). You can throw something together pretty fast in say java or vb test it out make sure it works then write it in assembly and you'll have a good working base to start optimizing it. writing it directly in asm and testing it there is IMHO easier than writing it in HLL and rewriting to asm Quote: -off topic - does FDBG still go into the kernel APIs while debugging? I remember an old version I used for win xp64 did that and it was so annoying having to step through the windows apis to get back to my code. Maybe there was an option to turn it off but I was just ignorant of it. |
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.