I'm in an Assembly class focusing on the intel 8086 architecture (all compiling / linking / execution comes from running DOS on win7 via DOS-Box).
I've finished programming the latest assignment, but as I have yet to program any program successfully the first time through, I am now stuck trying to debug my code.
I have visual studio 2010 and was wondering if there was some built in feature that would help me debug my assembly code, specifically, I'm looking to track the value of a variable.
Failing that, instructions pointing to a DOS-Box debugger (and instructions!) would be much appreciated. (I think I've been able to run codeview debug, but I couldn't figure out how to do what I was looking for).
You are generating 16-bit code, you have to break into a museum to find better tooling. Try Borland's, maybe the debugger included with Turbo C.
Yes, indeed, you can use the debugger in VS to examine pretty much everything. Irvine's site has a section specifically on using the debugger here. You can examine registers, use the watch window, etc. He also has a guide for highlighting asm keywords if you need that.
Edit: as Hans pointed out, if you are using 16-bit instead of 32-bit protected, you'll need different tools. There are several choices, listed here.
Borland's tools for DOS were called tasm, tlink, and tdebug.
Related
I'm new in Fortran and I need your help.
I'm a space engineering student and I'm used to code in MATLAB.
Right now I'm writing my MSc thesis and I have to deal with a code written in fortran77 (I'm guessing it by its extension ".for"). The code has already been tested and used in other occasions.
I use Windows 10 as an operating system and I know that sometimes an old code could show problems depending on the system in which it is run (for instance I've heard about the need of running old versions of an operating system through emulators to solve some problems).
I hope I can still use Win10 for the purpose.
So, I have done the following steps (based on what I have found on internet) in order to configure my system:
I have installed the last version of Microsoft Visual Studio Community 2019
I have installed Intel OneApi Basic Toolkit and then Intel OneApi HPC Toolkit (the last one is an add-on that contains the fortran compiler).
It seems that both are well configured/integrated and I think they are working properly.
Now, when I try to open the project from Visual Studio, the .for extension isn't apparently recognized.
So I've tried to open it as a simple file, and in doing so, I can visualize it on VS.
I don't know If It is the right procedure, and I don't know if it works as it should.
How can I prove it?
I try to run it, but nothing seems to happen (no error flag by the way).
I'm totally new in this field, so any "obvious" suggestions will be really appreciated.
I'm open to any tips, even If it is better to change compiler (I've heard about gfortran) or use other kinds of softwares. I would be also grateful if someone could suggest me a beginner useful guide.
Thanks to whoever wants to help me out.
I want to generate x86 assembly for a compiler course I have this semester.
My problem is that my only experience was a long time ago with 8086 assembler and I remember nothing.
I am looking for resources that have examples that will work with gcc(as) in order to test them.
My favourite documentation links:
http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
http://ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html
Please, take note of the Related links section at the lower-right of this very screen, as well
there is a nice 8088/86 emulator pcemu, I have a fork of it where I removed the bios and dos calls leaving a processor emulator for learning 8088/86. use nasm as an assembler and http://github.com/dwelch67/pcemu_samples or some other pcemu or similar simulator (where you can get good visibility into what is going on, printing each instruction in execution order for example).
If you didnt mean 8086 and meant the modern/current x86/IA processors, then pcemu wont work you need something like qemu (little to know visibility).
After Google the issue i found that it was reported already but nothing useful yet from MS. I wonder if any one found a work around it?
Another option is to use windbg. You'll have to do a lot of commands by hand, but it's the best debugger out there. It handles mixed mode without any major issues. It has a bit of a learning curve, but it's very versatile.
Visual Studio's debugger is really not reliable when debugging mixed mode applications. Taken from my answer here #5965771:
If you're trying to debug a piece of native code try to use a native project as the debugger start-up application. Under the project settings, "Debugging" tab set the "Debugger Type" to "Mixed", for us this helped sometimes (the native project can be a DLL for example, simply set your main Exe as debugging target in the project settings);
OR, as already mentioned in another answer: Use WinDbg! With it you can debug both managed/unmanaged mixed code applications much more reliably.
use a different debugger, or don't use the debugger at all, just trace to a file or insert breakpoints in the code with inline assembly language.
I'm writing a compiler that converts source code (written in a small imperative programming language) to Intel AT&T 32-bit assembler.
I tend to spend a lot of time debugging, because of nasty offset-mistakes etc. in the generated code, and I would like to know if anyone knows of a tool to "walk through" the generated assembler code step-by-step, visualizing what's on the stack etc.
I use Ubuntu Linux as my development platform, and I'm comfortable with the terminal -- a GUI-program would be nice though. Does it exist? Or is there a good reason it doesn't (maybe the problem isn't so straightforward..?)
If you have good ideas for approaching debugging tasks in assembly code, I'll be glad to hear from you!
I like EDB (Evan's Debugger) on Linux. It has a nice, easy-to-use, QT4-based GUI. Its developer's goal is to make it similar to OllyDbg. And it's being actively maintained:
EDB on FreshMeat
I'm pretty sure it's installable through Synaptic on Ubuntu as well. Enjoy!
Is the end result of the compile process something that you can actually execute, and therefore examine in a debugger? If so the Data Display Debugger (ddd) might be useful.
My experience with debuggers such as Olly and EDB is quite sparse, so I wasn't able to solve my problem with those. I ended up
scattering calls around to a Debug function in the source code, nailing down bad register values
letting the compiler output HTML-formatted code with useful metadata for different iterations in the liveness analysis etc.
I've been doing some MSIL work and have come across references to these three debuggers.
What's the difference between them?
Is one of them better than the others wrt. functionality?
Are there others that I have missed?
I'm assuming you meant DbgClr not Clt and mdbg not mdbug?
DbgClr uses the VS shell so you get a nice GUI.
mdbg is the command line managed debugger.
cordbg was an old sample that sorta shipped, but now it's just a wrapper for mdbg. http://blogs.msdn.com/jmstall/archive/2005/11/07/views_on_cordbg_and_mdbg.aspx
Visual Studio is one you missed, but DbgClr should have the same functionality. http://blogs.msdn.com/andypennell/archive/2005/02/21/377621.aspx.
You can also use windbg with SOS extensions to do managed debugging from Windows debugger. SOS is also helpful when using VS since it lets you inspect memory and so on.
To see source level MSIL debugging, try using ilasm with the /debug option. Last time I checked, VS will let you step through the .il source just like C# or any other language.
MSDN blogs have a ton of content about debugging .NET apps -- I suggest you search further there.