This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
|
Attachment:
Wipro_Disclaimer.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |