Re: Remote debugging of multithreaded programs using gdbserver

Daniel Jacobowitz
2002-04-19T16:16:31Z

On Fri, Apr 19, 2002 at 06:32:17PM +0530, Subhashini Nagarajan Rao wrote:
> 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).

I reached the point in my implementation where I needed this code
yesterday. I got it to work, but in the process gained a good
understanding for why it is done the other way in core GDB - because
otherwise, if a breakpoint is removed after two threads have hit it,
one of them will resume with the wrong PC and a bogus SIGTRAP.

You should be able to reproduce this with pthreads.c in the GDB
testsuite, by setting a breakpoint on common_function if hits >= 15,
continuing to it, disabling the breakpoint, and continuing again. That
most likely requires SMP in order to see it; I highly recommend testing
all thread-debugging work on SMP.

I think that this approach is still valuable, because it simplifies the
arbitration logic, but backing off of breakpoints may still be
necessary.

> **************************Disclaimer************************************
> Information contained in this E-MAIL being proprietary to Wipro Limited
> is 'privileged' and 'confidential' and intended for use only by the
> individual or entity to which it is addressed. You are notified that any
> use, copying or dissemination of the information contained in the E-MAIL
> in any manner whatsoever is strictly prohibited.
> ********************************************************************

This form of disclaimer violates the accepted policy for most mailing
lists; the GCC lists page explicitly says:

|Please do not include or reference confidentiality notices, like:
|
| The referring document contains privileged and confidential
| information. If you are not the intended recipient you must not
| disseminate, copy or take any action in reliance on it, and we request
| that you notify companyname immediately.
|
|Such disclaimers are inappropriate for mail sent to public lists. If
|your company automatically adds something like this to outgoing mail,
|and you can't convince them to stop, you might consider using a free
|web-based e-mail account.