Re: Porting gdb to Cyclops64

[Pedro Alves <pedro at codesourcery dot com>]

On Thursday 05 August 2010 14:56:48, Brian Heilig wrote:

> In my previous message I described a problem I encountered while
> stepping a multi-threaded program. Here is a general description of
> what's happening.
> 
> All threads execute in parallel (on their own core) on the Cyclops64
> chip. I implemented a queue on the gdb server to serialize events. This
> makes Cyclops64 look like a cooperatively scheduled architecture to gdb
> in stop mode.
> 
> While single stepping a single thread (let's call it thread 5) gdb
> decided to set a breakpoint at some address and continue all threads.
> All threads hit this internal breakpoint including thread 5. The
> breakpoint events for threads 1-4 are reported and ignored by gdb (gdb
> knows it doesn't care about these threads). Then thread 5 is reported
> and gdb removes the breakpoint. However the event for threads 6-n are
> still in the queue. The next time the user continues these events are
> reported. Since gdb removed the internal breakpoint it assumes these
> events must be caused by something else and doesn't filter them out.
> 
> Is there anything I can do about this?

Yes.  I'll suggest two alternatives.

 #1 - before reporting a delayed/queued breakpoint hit event, check
   whether there's still a breakpoint still inserted where the
   thread is stopped.  If there isn't, then just resume the thread
   without telling gdb about the stop.

 #2 - don't leave breakpoint hit events queued (all other events, yes,
   leave them).  When you've stopped all threads to report a breakpoint
   hit to gdb, go through all threads, and those that have stopped
   due to a breakpoint, simply forget their breakpoint hits.  The
   next time gdb resumes those threads, they'll immediately hit
   the same breakpoint again.  You'll most likely want to
   add a bit of randomness to which of the threads amongs those
   that have hit a breakpoint you're going to report to gdb.

#2 is what both native linux gdb and linux gdbserver implement
nowadays.  gdbserver used to implement #1 until recently.
#1 has the advantage that it's a bit more efficient since it
avoids resuming the target when not strictly necessary.  The
disadvantage is that it makes managing the PC adjustment after
breakpoint traps more complicated.  E.g., the stub needs extra
care to present to GDB already adjusted PCs for all those
threads that still have pending breakpoint hits to report to gdb
in the event queue, but, to unadjust them when finally report
the queued breakpoint hit, so that gdb itself does the necessary
adjustment.  This may not be a concern on Cyclops64, I don't know.

> Is there a facility to set a
> breakpoint for a single thread and filter them on the server? 

Nope, it's one of those IWBN things that nobody ever got around to
working on, AFAIK.

> Or is this
> just a consequence of gdb not knowing how to deal with an SPMD
> architecture yet?

Nope.

-- 
Pedro Alves