bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gdb handling of Mach exceptions


From: Brent W. Baccala
Subject: Re: gdb handling of Mach exceptions
Date: Wed, 23 Nov 2016 22:03:47 -1000

Hi -

I've been working with gdb on the test programs that Samuel posted to test signal preemptors.

It seems that gdb doesn't reliably intercept the task's exception port.  It intercepts it once, when it creates the child process, but then assumes that it doesn't change.  Something else, I think _hurdsig_init, at hurd/hurdsig.c:1581, then intercepts the task exception port again.

I've patched gdb to re-intercept the exception port every time it restarts the program.  It still doesn't work just right, but now, if I breakpoint main(), then continue from there, I can catch the memory access exception.  Here's the patch:

--- gdb/gnu-nat.c~  2015-08-28 11:22:07.000000000 -1000
+++ gdb/gnu-nat.c   2016-11-23 03:34:22.000000000 -1000
@@ -268,6 +268,9 @@
        proc->state_changed = 0;
     }
 
+  if (proc->sc == 0)
+    proc_steal_exc_port(proc, proc->inf->event_port);
+
   if (delta > 0)
     {
       while (delta-- > 0 && !err)

And here's the result:

(gdb) break main
Breakpoint 1 at 0x804864a: file mtest.c, line 20.
(gdb) run
Starting program: /root/mtest
[New Thread 29170.5]

Breakpoint 1, main (argc=1, argv=0x102ce04) at mtest.c:20
20      int main(int argc, char *argv[]) {
(gdb) cont
Continuing.
copying

Program received signal EXC_BAD_ACCESS, Could not access memory.
memcpy () at ../sysdeps/i386/i686/memcpy.S:90
90      ../sysdeps/i386/i686/memcpy.S: No such file or directory.
(gdb) cont
Continuing.
11 a0000001 0x102c95c
done
[Inferior 1 (pid 29170) exited normally]
(gdb)

Now I'm wondering how gdb catches breakpoints at all!  Watching its debug trace, it seems that the message stopping it at main() isn't exception_raise (2400), but rather proc_wait_reply (24120).  Are the breakpoints going to the process's message thread and getting converted into signals?  Yeah, the 'status' field in the proc_wait_reply is 0x57f, which is W_STOPCODE(SIGTRAP).  Wow.

I guess gdb, to work properly, has to do like rpctrace and wrap the task port, so that it can catch any calls to the task_set_special_port RPC.  Then we'll have problems detaching it from a process, as we've already discussed with rpctrace.

Any comments?

    agape
    brent


reply via email to

[Prev in Thread] Current Thread [Next in Thread]