On: How does mkdir() really work?

[Locke1689]

The first response about C not knowing how to do syscalls with multiple arguments is wrong. This kind of thing is done via the system syscall interface. In fact, the more I think about it the more wrong he becomes. System call interfaces don't have any such thing as "language dependence" -- if you can't do a syscall in straight object code you're screwed no matter what language you're using. The syscall intrinsic in C and C++ is a nonstandard Linux defined relation between the OS syscall interface (per the OS designation for the ISA) and code being run.

Here's how you do a 2-arg mkdir:

  push %rax
  push %rbx
  push %rcx
  movq $0x27, %rax
  movq $path, %rbx
  movq $mode, %rcx
  int $0x80

Here's how you do a 3-arg:

  push %rax
  push %rbx
  push %rcx
  push %rdx
  movq $0x128, %rax
  movq $dfd, %rbx
  movq $path, %rcx
  movq $mode, %rdx
  int $0x80

Edit: Hmm, maybe he was referring to overloading the intrinsic. That kind of makes sense, although there's a standard way to do that if necessary (first arg is number of args, just pop x off the stack after the call, see printf).

[rwmj → Locke1689]

"int $0x80" still works for backwards compatibility, but it's not been used for making syscalls from modern code for many many years.

[dododo → rwmj]

oh? on a recent glibc:

  $ objdump -D /lib/libc.so.6 | grep 'int[[:space:]]*$0x80' | wc -l
  447

what were you thinking they used instead? sysenter? iirc, this turns out to be slower than "int $0x80."

[Locke1689 → dododo]

I was also trying to be Intel/AMD ISA independent. The Intel is SYSENTER, the AMD is SYSCALL. He's right though, I probably would have used SYSENTER in production code. You probably want to use int $0x80 in shellcode, though (fewer save registers).

[rwmj → dododo]

On i386 perhaps, but on modern 64 bit machines like the one in the example code above it'll be using sysenter or another method.

$ objdump -D /lib64/libc.so.6 | grep 'int[[:space:]]+$0x80' | wc -l

0