Re: RFA/gdbserver: GDB internal-error debugging threaded program with breakpoint and forks

[Joel Brobecker <brobecker@adacore.com>]

> >   a. Make gdbserver "hide" the threads that are children of forks
> >      until we've reported the corresponding fork event to GDB.
> > 
> 
> Agreed, I think we need to do this.  It's somewhat what
> linux-nat.c does, except linux-nat.c hides the fork child
> until target_follow_fork time.  
[...]
> That said, I would still consider my current
> > patch, as reporting the forks early allow us to either detach
> > from them earlier.
> 
> My usual thought process is this: imagine we had (a) already.  Would we
> have a particularly strong reason to complicate the code and do (b) on
> its own?  Seems like not.  We could apply the same rationale for preferring
> to report any other thread stopped at a breakpoint before the fork
> events (so that we could move them past their breakpoints earlier).  Or
> always prefer the stepping thread, as that's the thread the user is most
> interested in (*).  Etc.
> 
> (*) - IIRC, the reason we prefer a stepped thread first is for
> correctness, not because that's what the user is focused in.  It used
> to be that if a step event got pending, and we reported some other
> event first, later when the pending step event is finally reported as
> a plain SIGTRAP, if the thread that had a pending step was now
> continued instead of stepped, infrun wouldn't understanding what this
> SIGTRAP was about, since the thread was no longer supposed to be
> single-stepping, and would thus report the SIGTRAP to the user as a
> spurious signal.  With "maint set target-non-stop on", which is still
> not the default with target remote,
> infrun.c:clear_proceed_status_thread handles this scenario on the gdb
> side and discards the single-step, but with plain all-stop, the
> spurious SIGTRAP probably would still happen.

I would have thought that we'd want GDB and GDBserver to be in sync
as quickly as possible, so as to release the new inferiors, but I guess
that doesn't really make any difference in practice. The issue with
reporting SIGTRAP from an old single-step is even more convincing that
my patch is actually wrong.  Sigh...

-- 
Joel