This is the mail archive of the gdb@sourceware.org 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]

Re: Behaviour of default all-stop mode -- Why no one has replied ?


On Monday 15 June 2009 11:37:53, suresh ds wrote:

> > Suppose three threads are running, say 1, 2, & 3.
> > Suppose thread 1 hits the breakpoint; It'll send the status to 
> > gdb; At this point, gdb itself will send (further) packets to 
> > stop other threads, or the stub itself should take the initiative 
> > to stop other threads ?
> 
> The stub.
> 
> ==>> So, the stub take the initiative to stop other threads. In this case, the other threads' status should also be reported to gdb ?

Nope.  The other threads are supposedly stopped without
anything interesting to report to GDB.  Only one event is
reported to GDB at a time.

If while your stub tries to stop all threads to report a stop
event to GDB (e.g., breakpoint hits in thread 1), one of those
threads hits another event (e.g., thread 2 gets signal)
then you have to deal with it.  E.g., leaving the extra events pending
until the next time GDB tells the threads to resume, or, by tweaking
the thread state so that the event would naturally trigger again
the next time you resume the threads.  If your stub is in-kernel, assuming
one core only, then usually you don't have to care for these complications,
as all threads are halted while the stub's code is executing.

> 
> 
> > 2) The document says, "whenever you restart the program, all 
> > threads start executing".
> > -- Again, the gdb takes initiative to continue all the threads or 
> > the stub should have a mechanism to do this ?
> > Suppose three threads, 1, 2, & 3 are in a stopped state.
> 
> See the vCont packet description.  That packet explicitly says what to resume,
> there's no all-stop vs non-stop magic in that aspect.
> 
> > Now, "continue" from thread 1 will continue all the threads ?
> > When I checked the packets, I found that it does only "Hc1" to 
> > set the further continue packets only for thread 1.
> 
> Implement vCont support instead, s,c,Hc are deprecated for 
> multithreaded stubs.
> 
> ==>> But I get indication from gdb only to start one thread; Maybe, this will change if the stub reports the status of all the threads initially ??

I think you're not reading the packet right, but this this is just
guessing, since now at this point, I don't know if you're talking
about vCont or c or s...  Please be specific.  

`vCont[;action[:thread-id]]...'
    Resume the inferior, specifying different actions for each thread.
    If an action is specified with no thread-id, then it is applied to any
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    threads that don't have a specific action specified;
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> I suggest studying the trafic between gdb and gdbserver.
> 
> ==>> I tried debugging a pthread program through gdbserver on intel-i386. But info threads was not recognizing the threads; I don't know if I should compile/configure gdbserver separately for thread mode ...

It should just work, if you run gdbserver on the same machine
as gdb.  Otherwise, you may be stumbling on point 6
at http://sourceware.org/gdb/wiki/FAQ.

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]