Re: Porting gdb to Cyclops64

[Pedro Alves <pedro@codesourcery.com>]

On Friday 30 July 2010 21:28:53, Brian Heilig wrote:
> Since all threads execute in parallel, more than one thread can hit a
> breakpoint. In stop mode I should stop all threads when the first thread
> hits a breakpoint. While stopping all threads other threads might hit a
> breakpoint. My intention is to queue these "events" and report them in
> sequential order to gdb. So that, in stop mode, when gdb tells the
> target to continue it will actually dequeue the next event. If there are
> no events then it will continue. Does this sound correct?

It does.

Only a little care should be taken to dequeue events for
threads that gdb is actually interested in.  Say, while stepping all
threads, some of the other threads hit breakpoints.  The next time the
user continues, gdb will want to step over the breakpoint that the
thread had reported being hit.  So, gdb removes this breakpoint and tells
that single thread to single-step over this location.  At this point, gdb
hadn't told any of the other threads to resume, so you shouldn't
dequeue any pending event for them yet.  (the same needs considering if
the user switches on scheduler-locking and resumes only one
thread --- your target should not report pending events for threads
that hadn't been resumed)

(this is what the lwp->resumed flag in gdb/linux-nat.c or
'struct thread_info'->last_resume_kind in gdb/gdbserver/server.c
implement)

> I guess I will have to implement non-stop mode as well since many
> threads can hit a breakpoint. It would be very inconvenient for my user
> to have to continue each thread individually. In this case I will not
> queue events but rather just send them to gdb and let gdb sort them out.
> Is this correct as well?

Not sure what you mean --- the user would still have to resume each
thread individually.  But yes, in non-stop mode, your target should 
let the other threads that hadn't hit any breakpoint continue running
free.

-- 
Pedro Alves