Quick summary about where we are: signals reach the Linux process, the
signal handler is run, but the Linux process crashes when the signal
handler exits.

I've used NetBSD's gdb on my Linux test program, and I can get some
information.

The signal trampoline is indeed invoked. When the process gets its trace
trap, I have this:

(gdb) x/20i $pc-32
0x7fffefcc:     nop
0x7fffefd0:     nop
0x7fffefd4:     nop
0x7fffefd8:     nop
0x7fffefdc:     nop
0x7fffefe0:     addiu   $a0,$sp,16   <-- this is the signal trampoline
0x7fffefe4:     li      $v0,119
0x7fffefe8:     syscall
0x7fffefec:     break
0x7fffeff0:     0x7fffe9f4
0x7fffeff4:     0x1
0x7fffeff8:     0x7fffe9fc
0x7fffeffc:     multu   $zero,$zero
0x7ffff000:     Error accessing memory address 0x7ffff000: Invalid
argument.

It seems I've gone through the signal trampoline. My first question is
about the break instruction: what is it supposed to do in MIPS assembly
exactly? I would have expected it to terminate my program immediatly...

Even more intersting: I used gdb to discover if yes or no I was
executing the signal trampoline. In fact, the answer can be found in a
simpe kernel trace:

   206 signal   PSIG  SIGHUP caught handler=0x400384 mask=() code=0x0
   206 signal   CALL  write(0x1,0x30000000,0x30)
   206 signal   GIO   fd 1 wrote 48 bytes
       "Signal Handler: sig=1  code=0x0  scp=0x7ff9f8a8
       "
   206 signal   RET   write 48/0x30
   206 signal   CALL  [-3881]
   206 signal   RET   [-3881] -1 unknown errno 78

Hence yes, I fo through the signal trampoline, but it does not work
because the system call which is called here is wrong: -3881 instead of
119.

Second question: how could 119 be transformed into -3881? I think I need
some input from someone which is confortable with the way system calls
work on the MIPS...




-- 
Emmanuel Dreyfus
manu@netbsd.org