[Bug threads/19471] unexpected stop in multi-inferior debugging

["palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19471

--- Comment #12 from Pedro Alves <palves at redhat dot com> ---
(In reply to Tom Tromey from comment #11)
> > IWBN if we had some sort of "catch inferior-exit" / "catch exit" catchpoint,
> which you'd use to stop when an inferior exits.  If we had that, switching
> to not stopping by default would be an even easier sell.
> 
> I started one once.  It's in my github, on the catch-exit branch.
> 
> It worked by using PTRACE_O_TRACEEXIT, so not exactly the same thing.
> I suppose on systems without that, it could fall back to
> target-waitkind-based
> stops.

That must have been for intercepting the exits before the process really exits?
Sort of like "catch syscall exit"?  Maybe so that you could still inspect
memory?  

What I was suggesting instead was just to have a way to have GDB stop after the
inferior dies, on TARGET_WAITIND_EXITED/TARGET_WAITIND_SIGNALED.  I.e., it'd be
totally an infrun.c/breakpoint.c thing, no target backend change necessary at
all.

> 
> It would need quite a bit of work now.  And, I never wrote the gdbserver
> or remote protocol parts.
> 
> > You should probably be calling resume or keep_going.
> 
> I tried what you suggested and it works, but I don't really know
> if it's correct or even close.

Next step would be testcases, exercising the several different scenarios, I
think.  all-stop/non-stop X single-process/multi-process X single-thread X
multi-threaded X set schedule-multiple on/off X set scheduler-locking on/off,
etc.

-- 
You are receiving this mail because:
You are on the CC list for the bug.