Re: Entrypoint for user-space syscall instruction

Never mind... It turns out that user thread goes into ALIEN_SYSCALL.

2018-03-26 19:09 GMT+08:00 Zihan Yang <[email protected]>:
> 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.