Hello, I'm new to these forums, and have just started programming in assembly.
I wrote a small program to print out the first command line argument, and it's not working. It goes like this:

section .data
	empty db "The pointer was null",10,0

section .text
 global _start
 _start:
	mov rcx, [rsp + 16]
	mov rbx, 1
	mov rdx, 40
	mov rax, 4
	int 80h
end:
	mov rax, 1

	int 80h
error_message:
	mov rcx, empty
	mov rbx, 1
	mov rdx, 22
	mov rax, 4
	int 80h
	jmp end

When I compile and run that, it just runs - no segmentation fault or anything, just runs. and it doesn't print out the first command line argument.
However, I tried using rep movsb to use the address in rcx to put the string in a buffer, like this(with 40 bytes reserved in section .bss for text):

mov rsi, rcx
mov rdi, text
mov rcx, 40
rep movsb

When I used linux syscalls to print out the 'text' buffer, It printed out the first argument, no problem. Why won't the above example work?
thanks in advance for any help.

I see you're using 64-bit instructions. What is int 80h?

I do see a problem!

mov rcx,empty is loading a 64-bit from memory at that location
mov rcx,offset empty loads the address of empty into the rcx register!

Edited 6 Years Ago by wildgoose: n/a

I see you're using 64-bit instructions. What is int 80h?

I do see a problem!

mov rcx,empty is loading a 64-bit from memory at that location
mov rcx,offset empty loads the address of empty into the rcx register!

The problem isn't the empty though, That's a leftover function that I used to call if rcx was zero. The error message works fine. It's the procedure further above that's giving me headaches, this here:

_start:
	mov rcx, [rsp + 16]
	mov rbx, 1
	mov rdx, 40
	mov rax, 4
	int 80h
end:
	mov rax, 1

	int 80h

int 80h is the same as int 0x80 in GAS, but in NASM syntax.
Sorry about not cleaning up my code. Thanks for the help

Is this a 32-bit Linux or a 64-bit Linux?

Are you building a 32-bit or 64-bit application?

64-bit. I am running a core2duo laptop with ubuntu 10.04 64-bit.
here's what I do to compile and run:

$ nasm -f elf64 commandlineargs.asm
$ ld -o args commandlineargs.o
$ ./args hello
$

nothing happens.

Edited 6 Years Ago by Quargar: n/a

So you're trying to write 40 bytes to the console.

Are you suring the stack offset is correct? Or that the value on the stack is the address of the ASCII string?

So you're trying to write 40 bytes to the console.

Are you suring the stack offset is correct? Or that the value on the stack is the address of the ASCII string?

Here's the part I'm not 100% sure about. See, I used reb movsb and the address at [rsp + 16] to write the string into a buffer (seeing as how it's convention to write the argument count, then argv0, then argv1 to the stack when the program starts for all ELF) and it worked. the first argument printed without a problem, when I gave the write to file operation (rcx) the buffer I had written it to. So I know that that string is there, and that if I go through an unweildly process, I get it to print to the console. What I want to know is why, if I simply move the address into rcx when I start up, it won't print to the console.

How many items on the stack?

Assuming:

Stack = 1000h
Push rax ; arg A
stack = 0FF8h
push rbx ; arg B
stack = 0FF0h
call FOOBAR

Stack = 0FE8h
[RSP+0] = Return Address
[RSP+8] = Var B
[RSP+16] = Var A

Assuming a near function call.

Edited 6 Years Ago by wildgoose: n/a

How many items on the stack?

Assuming:

Stack = 1000h
Push rax ; arg A
stack = 0FF8h
push rbx ; arg B
stack = 0FF0h
call FOOBAR

Stack = 0FE8h
[RSP+0] = Return Address
[RSP+8] = Var B
[RSP+16] = Var A

Assuming a near function call.

If I get what you're saying...
there are no items on the stack that I have put in. At startup, a standard ELF executable has
ARGC
ARGV[0]
ARGV[1]
...
and so on. I know that rsp is pointing to ARGC, and [rsp + 16] will point to ARGV[1], because when I do the whole rep movsb procedure, it wokrs. But there aren't any Items I have put on the stack. I hope I understood the question?

This article has been dead for over six months. Start a new discussion instead.