Re: Remote debugging of multithreaded programs using gdbserver

[Daniel Jacobowitz <drow at mvista dot com>]

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.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer