Entrypoint for user-space syscall instruction

Zihan Yang whois.zihan.yang at gmail.com
Mon Mar 26 13:09:09 CEST 2018


Hi,

I'm trying to figure out the entry for 'syscall' in Fiasco, I already
know that Fiasco will set MSR_STAR, MSR_LSTAR and MSR_CSTAR in
Cpu::setup_sysenter.

However, things don't seem right when I run a simple program of my
own, which is compiled statically outside in Ubuntu with gcc 5.4.0.
This program directly issues a single 'syscall' instruction (instead
of the syscall() function), which is equivalent to getpid().
Here is the program, which is compiled with gcc -static -o
syscall_single -O2 -std=gnu99 syscall_single.c
-------------------- BEGIN ---------------------
//syscall_single.c
//gcc -static -o syscall_single -O2 -std=gnu99 syscall_single.c
#include <stdio.h>

void printres(unsigned long res)
{
    printf("Done, id = %d\n", res);
}

int main()
{
    asm volatile(
        "mov  $39, %%rax\n"
        "syscall\n"
        "mov  %%rax, %%rdi\n"
        "call   printres"
        :
        :
        : "cc"
    );
    return 0;
}
--------------------- END ------------------------

Since Fiasco has specified MSR_LSTAR, I expect every normal system
call to goto the 'entry_sys_fast_ipc_c' in
src/kern/ia32/64/entry-native.S, therefore I add such line at the
beginning of entry_sys_fast_ipc_c
-------------------- BEGIN ---------------------
.extern unsigned long test_rax;
entry_sys_fast_ipc_c:
    movq  %rax, test_rax    //mov rax to the global variable test_rax
--------------------- END ------------------------
And I print this variable in 'sys_ipc_wrapper'.

Now strange things happen, when I type './syscall_single' in the
shell, test_rax is never 39 at any time! But yet it can get the right
result, and there is output in 'dispatch_system_call' in l4linux
side(manually added by me).

My questions are
(1) What is the entrypoint and actual path if a user program directly
issues a syscall instruction?
(2) I find dispatch_system_call judges whether there is a system call
based on the 'trap_nr' field of thread_struct, does this mean it is
implemented through exception?

Thanks.



More information about the l4-hackers mailing list