NASM Forum > Programming with NASM

bad syntax for EQU - when using aParam equ [rbp+16]

(1/1)

dindibo4:
Hello, i'm pretty new to NASM and I've tried to make a procedure like printf and assign the arguments with EQU


--- Code: ---; void printf(char *text, int len)
printf:
push rbp
mov rbp, rsp

aParam equ [rbp+16]
bParam equ [rbp+24]

mov eax, 4
mov ebx, 1
mov ecx, bParam
mov edx, aParam
int 0x80

pop rbp
ret
--- End code ---
 

It didn't worked and showed "bad syntax for EQU" exception on the code.
What is the right syntax of EQU for this usage?

fredericopissarra:
First. Since you are using the stack to pass the arguments for your function AND 'int 0x80', I assume you are dealing with 32 bits SysV ABI. You cannot use Rxx registers there.

Second, there is a better approach:

--- Code: ---bits 32   ; to be sure!

section .text

global putstr

; Stack frame for putstr() function call.
struc putstrstk
.retaddr: resd  1   ; call will push the return address.
.len:     resd  1   ; cdecl calling convention will push len first,...
.textptr: resd  1   ; ... then, textptr, before calling putstr().
endstruc

; void putstr(char *text, size_t len)
putstr:
  ; You don't need to use EBP!!!
  mov eax, 4      ; write syscall [write( int fd, void *buff, size_t size );]
  mov ebx, 1      ; stdout
  mov ecx, [esp + putstrstk.textptr]
  mov edx, [esp + putstrstk.len]
  int 0x80
  ret
--- End code ---

Third, EQU is not a lexical substitution directive. For that purpose you should use %define:

--- Code: ---%define aParam [ebp+4]
%define bParam [ebp+8]
--- End code ---

dindibo4:
I personally prefer the simpler method using by using %define because of simplicity, but thanks for the answer.

fredericopissarra:

--- Quote from: dindibo4 on July 04, 2019, 07:25:30 PM ---I personally prefer the simpler method using by using %define because of simplicity, but thanks for the answer.

--- End quote ---
Ok... just keep in mind that using the hardcoded [ebp+offset] can lead to bugs. In your example the offsets are wrong... Using the structure you avoid this problem.

Navigation

[0] Message Index