7

I know that in Linux x64 "syscall" and "int 0x80" assembler instructions generate an interrupt in software asking the kernel to do some work. They have different opcodes (0F 05 vs CD 80) and the former is faster.
It's not clear to me if there is any relationship between them: are they really independent? (i.e.: does "syscall" call "int 0x80"?) Thank you.

Antonio Rizzo
  • 748
  • 1
  • 8
  • 17
  • I don't know what the difference is, but both work in 64bit long mode, while only int 0x80 works in 32 bit mode, which suggests whatever the former does is not only more efficient, but would not use the same 32bit CPU features. I suspect it is related to the fact that 64bit long mode has a much simplified flat memory model (32bit is segmented). – teppic Apr 04 '15 at 00:09
  • In 64-bit code, only ever use `syscall`. See https://stackoverflow.com/questions/2535989/what-are-the-calling-conventions-for-unix-linux-system-calls-on-x86-64 for details on how (and on how to use `int 0x80` in 32-bit code.) – Peter Cordes Sep 03 '17 at 04:11
  • 1
    `int 0x80` invokes the 32-bit ABI (with its calling convention and syscall numbers) even when executed in a 64-bit process. This is never a good idea and ther's no benefit (`syscall` is faster). e.g. `eax=1` / `int 0x80` is sys_exit(), but `eax=1` / `syscall` is sys_write(). https://stackoverflow.com/questions/2500362/running-32-bit-assembly-code-on-a-64-bit-linux-64-bit-processor-explain-the/46020177#46020177 – Peter Cordes Sep 03 '17 at 04:13

3 Answers3

6

The syscall (x86-64) and sysenter (x86-32) instructions are newer and faster, and so are used when available; but the int 0x80 mechanism is preserved for compatibility with old binaries. There is no semantic difference -- system call numbering is the same regardless of which instruction is used to transfer control into the kernel, and I think the arguments are all in the same places as well.

I have a dim recollection of there being a small number of system calls that could only be made using int 0x80 because of their unusual stack-related behavior (clone? execve? sigreturn?) but that might no longer be true.

zwol
  • 135,547
  • 38
  • 252
  • 361
  • Related: **[What happens if you use the 32-bit int 0x80 Linux ABI in 64-bit code?](https://stackoverflow.com/questions/46087730/what-happens-if-you-use-the-32-bit-int-0x80-linux-abi-in-64-bit-code)**. `int 0x80` is the 32-bit ABI (with 32-bit call numbers and registers), even when you use it from 64-bit user-space. (`strace` decodes it wrong, as if it was `syscall`. Perhaps this is why your answer incorrectly claims that it doesn't matter how you enter the kernel?) – Peter Cordes Mar 14 '18 at 12:18
1

int 0x80 is rumored to be obsolete (since slow). BTW, you really want to use vdso(7)

AFAIK, both instructions are going inside the kernel, and each has some (short) sequence of kernel processing which ultimately jump into the syscall table.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
1

int 0x80 is the 32-bit interrupt used with 8086 - 80386 assembly. x86_64 uses syscall in its place. See the differences in /usr/include/asm/unistd_32.h and unistd_64.h for the different call numbers each expect to invoke the various kernel functions.

David C. Rankin
  • 81,885
  • 6
  • 58
  • 85
  • "int 0x80" works in x64 too. In x86 there is sysenter; so the question is the same: is there a relationship between sysenter and int 0x80? – Antonio Rizzo Apr 03 '15 at 22:19