Re: gdb handling of Mach exceptions

2016-11-24 Thread Brent W. Baccala
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.0 -1000
+++ gdb/gnu-nat.c   2016-11-23 03:34:22.0 -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 a001 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


Re: gdb handling of Mach exceptions

2016-11-24 Thread Svante Signell
On Wed, 2016-11-23 at 22:03 -1000, Brent W. Baccala wrote:
> 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 do also see Program received signal ?, Unknown signal  when running
gdb on temacs (from emacs25):
Program received signal ?, Unknown signal.
_hurd_port_get (link=0x102c870, port=0x24) at ../hurd/hurd/port.h:122
bt full see http://paste.debian.net/898594/

FYI: rpctrace temacs makes the box exit with a memory exhaustion
message:
...
task776(pid441)->mach_port_mod_refs (pn{  4} 1 -1) = 0 
task776(pid441)->vm_allocate (139407360 12288 0) = 0x3 ((os/kern) no
space available) 
Child 441 Killed
Coming from error codes for Mach and Unix kernels:
mach/err_kern.sub:"(os/kern) no space available",