This is the mail archive of the
mailing list for the GDB project.
Re: RFA/gdbserver: GDB internal-error debugging threaded program with breakpoint and forks
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 5 Jul 2016 09:49:39 -0700
- Subject: Re: RFA/gdbserver: GDB internal-error debugging threaded program with breakpoint and forks
- Authentication-results: sourceware.org; auth=none
- References: <20160512171650.GC26324@adacore.com> <5734C06C.firstname.lastname@example.org> <20160623225935.GC3295@adacore.com> <20160624181152.GD3295@adacore.com> <email@example.com> <20160624223616.GE3295@adacore.com> <firstname.lastname@example.org> <20160627223200.GF3295@adacore.com> <email@example.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...