How does 32-bit system call table entry point maps to SYSCALL_DEFINE in x86_64

Question

I am digging deeper into system calls,

Added a system call into both syscall_32.tbl and syscall_64.tbl

syscall_32.tbl

434     i386    hello           sys_hello           __ia32_sys_hello

syscall_64.tbl

434 common  hello           __x64_sys_hello

Definition:

SYSCALL_DEFINE0(hello) {
    pr_info("%s\n", __func__);
    pr_info("Hello, world!\n");
    return 0;
 }

User space code:

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <sys/syscall.h>
#include <string.h>
int main(void)
{
    long return_value = syscall(434);

    printf("return value from syscall: %ld, erron:%d\n", return_value, errno);
    return 0;
}

When i run this user space code on x86_64, i get the following output in dmesg

$ gcc userspace.c -o userspace

[  800.837360] __x64_sys_hello
[  800.837361] Hello, world!

But when i compile it for 32-bit, i get

$ gcc userspace.c -o userspace -m32

[  838.979286] __x64_sys_hello
[  838.979286] Hello, world!

How come the entry point present in syscall_32.tbl (__ia32_sys_hello) maps to __x64_sys_hello?

Answer 1

On a 64-bit kernel, SYSCALL_DEFINE0 defines the compat (32-bit) and other ABI (eg x32 on x86_64) syscall entry points as aliases for the real 64-bit function. It does not define (and has no way to define; that's not how the preprocessor works) multiple functions built from a single body appearing after the ) of the macro evaluation. So __func__ expands to the name of the actual function that has __func__ written in it, not the name of the alias.

For SYSCALL_DEFINEx with x>0, it's more complicated since arguments have to be converted, and I believe wrappers are involved.

You can find all the magic in arch/x86/include/asm/syscall_wrapper.h (under the top-level kernel tree).

If you really want/need there to be separate functions, I believe there's a way to skip the magic and do it. But it makes your code harder to maintain since it may break when the mechanisms behind the magic break. It's likely preferable to probe whether the calling (current) userspace process is 32-bit or 64-bit and act differently according to that.