Hi!

The signal stuff now seems to work. The Signal handler is invoked, and
it returns without crashing the process (nor the kernel ;o) ). I still
have a problem with sigcontext and code parameters of the signal handler
been exchanged on a real Linux/PowerPC system (should I emulate this
"feature" too?). Even more surprising, they are both set to 0 on a
Linux/i386 system. Again, if someone could check this on other Linux
boxes, here is the sample code:

#include <stdio.h>
#include <unistd.h>
#include <signal.h>

void* func (int, int, struct sigcontext*);


int main (int argc, char** argv) {
        printf("Starting execution\n");
        if (signal(SIGHUP,*func))
                perror ("signal() failed");     
        printf("signal() successful. Now sleeping\n");
        while (1) 
                sleep (600);
        printf("I should not come here\n");
        return 0;
}

void* func (int sig, int code, struct sigcontext* scp) {
        printf("Signal Handler: sig=%d  code=0x%x  scp=0x%lx\n",sig,
code, (unsigned long)scp);
        return NULL;
}

Now, new problems: first, I don't know what happens for multiples
signals, I'll check this tomorow.

Second, I tried to use Linux's bash. Here is my command line:
./sh -c "echo toto| ./awk '{print $1}'"

It fails, with a bunch of "linux_old_to_native_sigaction: sa_restorer
ignored" on the console. I assume there is more work to do on signals,
but on the kernel trace, it's not easy to understand what actually
caused the problem. It seems it could be usefull to be able to really
trace pograms now. I did not write the linux_sys_ptrace file, but do I
need it to trace a Linux binary with the NetBSD gdb? (isn't that
linux_sys_ptrace usefull to have a Linux binary be the tracer?)

If I try to run NetBSD's gdb on a hello world program, here is what I
get:
(gdb) b main
Breakpoint 1 at 0x1800654: file hello.c, line 3.
(gdb) run
Starting program: /usr/local/src/linux/bin/hello.dyn 
warning: Unable to find dynamic linker breakpoint function.
warning: GDB will be unable to debug shared library initializers
warning: and track explicitly loaded dynamic code.
/lib/libc.so.6: No such file or directory.

Where should I start looking for bugs? Is this that gdb takes care of
loading dynamic libraries itself and that it does not uses Linux's
ld.so? 

-- 
Emmanuel Dreyfus.  
Hiroshima 45. Tchernobyl 86. Windows 95. 
p99dreyf@criens.u-psud.fr