Fairly simple question this time. How do I write to screen the contents of a single register in Assembly? I'm getting a bit tired of calling DumpRegs just to see the value of one register.
I'm using x86 architecture, and MASM in Visual Studio, and Irvine32.lib.
Irvines's DumpReg uses repeatedly a macro of Macros.inc: mShowRegister. It can be used directly. Example:
INCLUDE Irvine32.inc
INCLUDE Macros.inc
.code
main PROC
mov esi, 0DeadBeefh
mShowRegister ESI, ESI
exit
main ENDP
END main
A documented macro with more options is mShow. Example:
INCLUDE Irvine32.inc
INCLUDE Macros.inc
.code
main PROC
mov esi, 0DeadBeefh
mshow ESI, h
exit
main ENDP
END main
Irvine32 has output functions that take a value in EAX, such as WriteDec (unsigned base 10).
See the documentation http://programming.msjc.edu/asm/help/source/irvinelib/writedec.htm which has links to WriteHex (hex = base 16), and WriteInt (signed base 10).
These functions use the Irvine32 calling convention and preserve all registers, including the arg-passing register EAX, so you can even insert them as a debug-print for EAX at least. More usually you'd use them as simply normal output functions.
Usually for asm debugging you'd use a debugger, not debug-print function calls.
Related
Back in the 1970's I cut my teeth on the IBM 370 mainframe assembler, and in the early 1980's I had the original IBM PC, with the Microsoft Macro Assembler. At that time it was sold as a separate product, and came with a very useful manual. Now I'm retired, in quarantine, and looking to get back into assembler language.
I downloaded Visual Studio 2019 Community, which has MASM included in it, and for interactive debugging I'm using x64dbg. My PC is 64 bit, so I'm using the ML64 assembler as provided with VS.
My question is regarding the calling convention for the Windows API functions.
These days the Windows functions all seem to be geared toward C++ and, in my understanding, the calling convention reflects the machine code that is generated by C++ for calling those functions. I want to develop a template that I can use for all future calls, so it's coded for a nonexistent function called apifunc. This fictional function has five parameters.
; command to assemble is:
; ml64 samplecall.asm /link /subsystem:windows /defaultlib:kernel32.lib /entry:Start
extrn ExitProcess: PROC
extrn apifunc: PROC ; any hypothetical api function with five parameters
.data
;
parm1 dword ? ; these could be any required data type
parm2 dword ?
parm3 dword ?
parm4 dword ?
parm5 dword ?
;
.code
Start PROC
;
sub rsp, 32 ; room on the stack for first four parameters, 8 bytes each
;
lea rcx, parm1 ; pass the first four parameters in registers
lea rdx, parm2
lea r8, parm3
lea r9, parm4
lea rax, parm5 ; address of the fifth and last parameter
push rax ; put it on the stack
call apifunc ; call the hypothetical function
;
call ExitProcess
;
Start ENDP
End:
Does this code look even remotely correct? When control returns from apifunc, do I have any indication at all of whether it was successful and, if it was not, why not? Do I need to add 40 back to the stack pointer in order to leave it in the same condition in which it was passed to me?
Please be patient with me, because I now stand at the bottom of a very steep learning curve. I hope my questions make sense, and that I provided enough information.
I am a newcomer to assembly trying to understand the objdump of the following function:
int nothing(int num) {
return num;
}
This is the result (linux, x86-64, gcc 8):
push rbp
mov rbp,rsp
mov DWORD PTR [rbp-0x4],edi
mov eax,DWORD PTR [rbp-0x4]
pop rbp
ret
My questions are:
1. Where does edi come from? Reading through some intro docs, I was under the impression that [rbp-0x4] would contain num.
2. From the above, apparently edi contains the argument. But then what role does [rbp-0x4] play? Why not just mov eax, edi?
Thanks!
Where does edi come from?
... From the above, apparently edi contains the argument.
This is the calling convention (for Linux and many other OSs):
All programming languages for these OSs pass the first parameter in rdi. The result (value returned) is passed in rax.
And because your C compiler interprets int as 32 bits, only the low 32 bits of rdi and rax are used - which is edi and eax.
Programming languages for Windows pass the first parameter in rcx...
But then what role does [rbp-0x4] play?
Using rbp has mainly historic reasons here. In 16-bit code (as it was used in 1980s and 1990s PCs) it was not possible to address data on the stack using the sp register (which corresponds to rsp). The only register that allowed addressing values on the stack easily was the bp register (corresponding to rbp).
And even in 32- or 64-bit code it is more difficult to write a compiler that addresses local variables (on the stack) using rsp rather than using rbp.
The compiler generates the first 3 instructions of assembler code before it knows what is done in the C function. The compiler puts the value on the stack because you could do something like address = &num in the code. This is however not possible when num is in a register but only when num is located in the memory.
Why not just mov eax, edi?
If you tell the compiler to optimize the code, it will first check the content of the C function before generating the first assembler instruction. It will find out that it is not required to put the value into the memory.
In this case the code will indeed look like this:
mov eax, edi
ret
I've spend lot of time trying to solve this problem and I don't understand, why it doesn't work. Problem's description is in comments below:
.386
.MODEL FLAT, STDCALL
OPTION CASEMAP:NONE
.NOLIST
.NOCREF
INCLUDE \masm32\include\windows.inc
.LIST
.CODE
DllEntry PROC hInstDLL:HINSTANCE, reason:DWORD, reserved1:DWORD
mov eax, TRUE
ret
DllEntry ENDP
caesarAsm proc string: DWORD, key: DWORD, stringLength : DWORD
mov esi, 1 ; I cannot use this register, mov esi, (anything) causes Crash:
; Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention
mov eax, string
ret
caesarAsm endp
END DllEntry
I searched "whole" Internet, I found that the problem is connected with stack, but no operation on stacks helped me to solve it.
I'm using Microsoft Visual Studio 2012
I assume the error does not occur in this function, rather, it is triggered elsewhere. The esi register is a callee-saved register. You must make sure its value is the same at function exit as it was at entry. You can use it in your function, but you must save and restore its value. Such as:
push esi
mov esi, 1
mov eax, string
pop esi
ret
This is all well documented. You may only use eax, ecx and edx without saving.
Side note: you are using high-level features of your assembler, you might want to check the actual generated code or refrain from using them until you are confident in what the result is going to be. Incidentally masm has a USES keyword which would do the save/restore for you.
I am doing some assembly homework and thought the best way to get my head around what is going on is to watch what happens in the registers as the program runs. In Visual Studio You can view the registers but I am doing an operation that only changes things in the lower 8-bits of one of my registers so im not sure what I should be looking at. Can anyone help me out?
Here's the question and the code I'm running:
What will be the hexadecimal value of the destination operand after each of the following instructions execute in sequence?
TITLE MASM Template (main.asm)
INCLUDE Irvine32.inc
.data var1 SBYTE -4, -2, 3, 1
.code main PROC
call Clrscr
mov al, var1 mov ah, [var1+3]
exit main ENDP
END main
Im pretty sure the answer is -4 after the first statement and 1 after the second statement but I want to see it in the registers.
and the register window i have to look as in VS:
The ah and al registers are just aliases for the lower two bytes of eax, and so you can just monitor the eax entry in the register window. In your example, ah is 0x36 and al is 0x65. You might also need mov al, [var1] to get the value at that address, but I am not sure about that.
I'm trying to call the following function:
long long RtlLargeIntegerDivide(long long dividend, long long divisor, long long* pRemainder)
in assembly code (NASM). It uses the stdcall calling convention, and it returns the quotient. These are the specifications:
Input: [EDX,EAX] (dividend), [ECX,EBX] (divisor)
Output: [EDX,EAX] (quotient), [ECX,EBX] (remainder)
How do I go about doing this? (My main problem is not exactly understanding EBP and ESP, and how they relate to local variables.)
(And no, this isn't homework; I'm trying to implement a wrapper C run-time library.)
Thank you!
In 32 bit mode you don't have to use EBP to access local variables at all, that is just a convention remnant from 16 bit times and doesn't concern us now anyway.
ESP is your stack pointer, I assume you know that. You can "allocate" space for your local variables by decrementing ESP.
stdcall calling convention uses the stack for argument passing. They are in normal order when on the stack, but if you are using PUSH that means you push them reversed. Integral return values are in EAX (and EDX when necessary). The called function cleans up the arguments from the stack.
So the following code should do what you want:
sub ESP, 8; make room for remainder
push ESP ; pass pointer to remainder as argument
push ECX
push EBX ; pass divisor argument
push EDX
push EAX ; pass dividend argument
call RtlLargeIntegerDivide
; quotient returned in EDX:EAX
; so just load remainder from stack
pop EBX
pop ECX
(For speed, you can use MOV instead of PUSH/POP)