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

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

[tromey at sourceware dot org]

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

--- Comment #14 from Tom Tromey <tromey at sourceware dot org> ---
I've been thinking about this today and wondering how useful
"catch exit" would be.  Seems easy enough to implement but what
scenario would I use it in?

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

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

[mark at klomp dot org]

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

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at klomp dot org

--- Comment #15 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Tom Tromey from comment #14)
> I've been thinking about this today and wondering how useful
> "catch exit" would be.  Seems easy enough to implement but what
> scenario would I use it in?

Sometimes an internal sanity check calls exit when detecting something odd
going on. It would be useful to catch where/when that happens with catch exit.

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

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

[tromey at sourceware dot org]

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

--- Comment #16 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Mark Wielaard from comment #15)
> (In reply to Tom Tromey from comment #14)
> > I've been thinking about this today and wondering how useful
> > "catch exit" would be.  Seems easy enough to implement but what
> > scenario would I use it in?
> 
> Sometimes an internal sanity check calls exit when detecting something odd
> going on. It would be useful to catch where/when that happens with catch
> exit.

In the implementation we're discussing, the stop would happen
after the process already exited.  Would that still be useful?
I can see it being useful with the TRACEEXIT implementation since
memory would still be available... but I have trouble picturing
using the infrun implementation.
(Also you can "catch syscall" to catch exits, I think.  Except
signals, but those usually cause stops anyway.)

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

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

[mark at klomp dot org]

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

--- Comment #17 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Tom Tromey from comment #16)
> (In reply to Mark Wielaard from comment #15)
> > Sometimes an internal sanity check calls exit when detecting something odd
> > going on. It would be useful to catch where/when that happens with catch
> > exit.
> 
> In the implementation we're discussing, the stop would happen
> after the process already exited.  Would that still be useful?
> I can see it being useful with the TRACEEXIT implementation since
> memory would still be available... but I have trouble picturing
> using the infrun implementation.
> (Also you can "catch syscall" to catch exits, I think.  Except
> signals, but those usually cause stops anyway.)

Yes, I was hoping it would work like stop signals.
Then you simply where to see the cause of the exit.

The trouble with catch syscall is that you have to remember all the various
exit/exit_group/etc/ syscalls you need to catch for it to work properly.

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

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

[tromey at sourceware dot org]

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

--- Comment #18 from Tom Tromey <tromey at sourceware dot org> ---
> The trouble with catch syscall is that you have to remember all the various
> exit/exit_group/etc/ syscalls you need to catch for it to work properly.

Now that you mention it, I've had this problem as well.
Thank you.

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

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

[tromey at sourceware dot org]

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

--- Comment #19 from Tom Tromey <tromey at sourceware dot org> ---
Created attachment 14473
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14473&action=edit
basic patch

This implements the basic functionality.

I wasn't super sure about the condition.  Checking sched_multi
made sense to me, but I wasn't sure if anything special was
needed for scheduler locking or non-stop.  Like, maybe in non-stop
we should skip the restart as well, on the theory that everything
the user wants running is already running.

I also have the start of "catch exit", but one issue with
implementing that is that there's no event_thread in the 'ecs'.
So, there's nowhere to put the bpstat.

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

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

[tromey at sourceware dot org]

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

--- Comment #20 from Tom Tromey <tromey at sourceware dot org> ---
I tried some hacks to make "catch exit" work, but without
success.  I'm not totally sure what's going on yet but
it seems clear to me now that we probably can't stash the
bpstat for a "catch exit" on the thread.

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

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

[tromey at sourceware dot org]

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

--- Comment #21 from Tom Tromey <tromey at sourceware dot org> ---
One idea I had is that it might be an ok compromise to
not stop when the inferior is marked "removable".

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