Re: Multi-threading support on DragonFlyBSD

> If another thread (that is being ran freely) happens to hit a breakpoint
> while single stepping the selected thread, then indeed you should report
> that SIGTRAP.  GDB will present that stop to the user, and the step will
> be aborted.  The stepping thread will be asked to stop, and will be
> stopped at an arbitrary place.

Ok, that means I got the "abort the step" part wrong.

> I think that the SIGTRAP at #10 is spurious.  It is perhaps a leftover
> from the step command at #5/#6?

Yes, it is, I didn't think this was a leftover though. 🙂

> When thread 2 hits breakpoint_2 at #7, then the step from thread 1
> aborts and should be forgotten.  When you step again at #8/#9, you start
> from a blank slate.

Got that, too. Currently, I made sure to report to GDB result of every 
event it requested to get. Apparently, that's not how it should work.

> It's possible that the code path taken in that case clears something
> that causes the spurious SIGTRAP to be forgotten.

I think there's no spurious SIGTRAPs for other threads, for GDB it looks 
like the inferior runs only single thread at this point in time.
I can be wrong on that one.

> Ok, so if I understand correctly, you do some kind of "ptrace resume",
> which is blocking, and it unblocks when something happens.  When that
> returns, the kernel has stopped all threads for you.  In a sense that
> simplifies some things, but it would make async/non-stop harder to
> implement.

Yes, it's a "ptrace wait" request which is blocking, I have "ptrace 
resume", too, which doesn't block. I'm ok to change both user and kernel 
space if that would make GDB usage better for end user.

> This kind of logic is managed at a higher level (infrun), not by
> targets.  I don't think that your target_ops::wait method is the place
> for such decision.  I'm not super familiar with this, I just know it's
> managed by spaghetti-like functions like `handle_signal_stop`.

OK, it makes sense. Thanks for your comments, it's rather eye-opening 
experience. My mental model about how gdb core operates is really wrong.

> Given what you said above, about how your debug interface works,
> non-stop/async is probably not a priority.

Well, I implemented the kernel part myself. So if it doesn't fit GDB 
(and later LLDB), then I can redo that.
Any information about how one should implement target dependent code for 
GDB is appreciated. Wiki pages, articles, existing "canonical" targets 
to learn from (maybe less complex than Linux one?), etc.

-Sergey