I see what you did there, cool.

Speaking of calling programs in terminal, I tried to get arguments to a program. I read online that the first element in stack is the number of arguments (argc) and after it there are argc elements.

I tried the following to print out the first argument, but it failed:


Code:


The comments should help you understand it. I would like to know if any of you knows why it doesn't work, I called it "./arguments hello".

Fundamentally wrong assumption there. You're not using the C runtime, so you don't get argc and argv (unless I'm mistaken)- you'll need to ask the system for them, and I don't know offhand how you'd do that for Linux.

According to this, the arguments are located on the stack with the element that gets popped first containing the number of arguments. Then the rest of the arguments are located on the stack as well, just pop them off accordingly.

Looks to me like your arguments to write() are weird. Should be write(int fd, const void *buf, size_t count), but the signature I'm inferring from your code is more like write(GARBAGE, const void *buf, int fd).

Popping rax (a 64-bit value) when you're trying to get 32-bit values back out is probably also not going to work at all. Since it seems everything you're getting in is 32 bits wide, you're getting garbage by popping 64-bit-wide values. If my quick mental work-through is correct, you're getting argc and argv[0] in rax after the first pop, then argv[1] and argv[2] in rax following the second pop. I think that given the endianness (x86 is little-endian), you actually have argv[1] in the high 32 bits of rax.

I think I noted this earlier- you seem to be mixing 32 and 64-bit ABIs, and I'm amazed it works. You're assembling 64-bit (hence the assembler not letting you use 32-bit registers with push/pop) but using the system's 32-bit ABI, which might break horribly when you start throwing around pointers, depending on where they actually are in memory. I wrote a quick program in C that's similar to yours and compiled it on a 64-bit system as a 64-bit binary, and the results are rather different (especially for syscalls):

Code:

Disassemblies, my own comments within:

Code:

You'll note that it's throwing around 64-bit pointers and using 32-bit register specifiers where possible to save on code space. In most cases, constants get sign-extended out to 64 bits when you use the 32-bit register parts, but you can't make any assumptions about what your pointers will be doing.

Hmmmmmm Thanks a lot Tari and Souvik. I know fixed the way I write the arguments. However, I have a bigger problem.

I need to get the length of a string located in a register.


Code:


I save the first actual argument to rcx, which is the 64-bit register of "ecx", where I save the string to be display by write().

However, I still need to save the length of the string in edx.

Also, I'm using 64-bit registers in the above code.

Since nobody's replied for over a week now, I'll bite. Getting the length of a string is pretty easy. As someone probably already mentioned in this thread, C strings are nul-terminated. This means you just have to count characters until you hit a zero character (ASCII NUL, not "0").

I don't have actual x86/x86-64 code to do this, but here's a C implementation:
Code:

I'll leave translating that to assembly language as an exercise for you.

And indeed it's a trivial four- or five-line implementation in x86, very clean indeed. I wouldn't even be surprised if deep within the x86 there's some kind of loop-and-compare-until instruction.