Hi Daniel,
With reference to your comment on the
PC-adjustment, we tried to avoid it and
the design for that is given below. I had also
tested with this change and things
are working fine. Requesting your valuable comments
on this.
In order to avoid the PC-adjustment for the threads
other than the thread of
interest (thread_to_cont), we can remember the
stop_event for the other threads.
which may require the following,
i) A boolean, has_pending, in the threadid_info structure to denote
that that
particular thread has got a trap event
(due to hitting a breakpoint) pending. This
should be initialised to 0.
(Note - in the details that follow, thread_to_cont
refers to the thread of interest,
'tp' refers to a thread in the list of current threads in
the
program maintained in 'threadid_list' )
The changes to be made are,
i) In
stop_all_threads(), if it is found that a thread has hit a breakpoint
then set the boolean tp->has_pending. Remove the code
corresponding
to cancelling of breakpoints.
ii) Do not reset tp->status for the threads which has tp->has_pending
set as
it will have the trap event recorded. (This will
be automatically taken care of
if the code corresponding to
cancellation of breakpoints is removed).
If a 's' packet is sent, it
indicates that the current thread is single-stepped
and hence the resume
logic will be kept the same except that those threads
having a pending event
will not get resumed.
If a 'c' packet is sent, it means the previous hit
breakpoint is cleared and
now we can look into the threads having a pending
event. Select the first
thread in the threadid_list having a
tp->has_pending equal to 1 and update the
thread_to_cont and the
general_thread (so that we fetch the register info of the
correct thread) to
this thread id. Reset tp->has_pending to indicate its selection.
As all the other threads are already stopped the
prepare_resume_reply should be
called with this updated thread_to_cont with status
set to 'T'.
An 's' or 'c' packet now will be similar to what is stated
above.
As the pending trap events are getting serviced
whenever a 'c' packet is sent , this
eliminates the need to have the arbitration logic
of selecting the next thread to
continue in the function select_event_pid(). [The
arbitration logic is explained in the
approach document under the subtitle - Procedure of
waiting for the inferior process to return the status.]
- Subha