int 80 doesn't appear in assembly code

Question

Problem

Let's consider:

int main(){
write(1, "hello", 5);
return 0;
}

I am reading a book that suggests the assembly output for the above code should be:

main:
mov $4, %eax
mov $1 %ebx
mov %string, %ecx
mov $len, %edx
int $0x80

(The above code was compiled with 32 bit architecture. Passing arguments by registers isn't caused by '64 bit convention passing arguments by registers' but it is caused by the fact, we make a syscall. )

And the output on my 64 bit Ubuntu machine with: gcc -S main.c -m32 is:

pushl   $4
pushl   $string
pushl   $1
call    write

My doubts

So it confused me. Why did gcc compile it as "normal" call, not as syscall. In this situation, what is the way to make the processor use a kernel function (like write)?

Answer 1

I am reading a book that suggests the assembly output for the above code should be ...

You shouldn't believe everything you read :-)

There is no requirement that C code be turned into specific assembly code, the only requirement that the C standard mandates is that the resulting code behave in a certain manner.

Whether that's done by directly calling the OS system call with int $80 (or sysenter ), or whether it's done by calling a library routine write() which eventually calls the OS in a similar fashion, is largely irrelevant.

If you were to locate and disassemble the write() code, you may well find it simply reads those values off the stack into registers and then calls the OS in much the same way as the code you've shown containing int $80 .

---

As an aside, what if you wanted to port gcc to a totally different architecture that uses call 5 to do OS-level system calls. If gcc is injecting specific int $80 calls into the assembly stream, that's not going to work too well.

But, if it's injecting a call to a write() function, all you have to do is make sure you link it with the correct library containing a modified write() function (one that does call 5 rather than int $80 ).