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

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

[suresh ds]

Thanks for the reply. I've some more queries, interspersed with ==>>

Regards,
Suresh


----- Original Message -----
From: "Pedro Alves" 
To: gdb@sourceware.org
Cc: "suresh ds" 
Subject: Re: Behaviour of default all-stop mode -- Why no one has replied ?
Date: Wed, 10 Jun 2009 18:56:12 +0100


> On Wednesday 10 June 2009 08:18:19, suresh ds wrote:
> Re: Behaviour of default all-stop mode -- Why no one has replied ?

Because we're all volunteers and busy people here.

On Wednesday 10 June 2009 08:18:19, suresh ds wrote:
> I'm re-posting my previous query.

Replying to the other query would be better, in terms
of preserving answers close to the questions, so that
other people googling around with the same problem have
better chances of finding them.

> The foll. are w.r.to remote debugging in gdb 6.8 cross-compiled for mips64.
>
> In the default all-stop mode,

Non-stop mode was only added post 6.8, so, this is about how GDB
has behaved since ever.

>
> 1) The document says, "whenever your program stops under GDB for 
> any reason,all threads of execution stop, not just the current 
> thread"
> -- Here, the initiation is done by gdb or the (remote) stub 
> should take care of this ?

The stub.

> 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 ?


> 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 ??


> The document does not clearly explain whether the initiative, to 
> stop all the threads once a thread hits a break and to continue 
> all the threads if a continue is given from a thread, is the 
> responsibility of gdb or stub, and how. And an inspection of 
> gdb's packets sent to stub throw no light either.

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 ...


I did find this in "D.10 Remote Protocol Support for Non-Stop Mode":

  "(...) In contrast to all-stop mode, where all threads in all processes
   are stopped when a stop reply is sent, in non-stop mode only the 
thread reporting the
   stop event is stopped.  (...)",

you can infer the all-stop behaviour from this, but, I agree with you that
it would be nice to clarify these points closer to the packet descriptions.

--
Pedro Alves


-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com

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

[Pedro Alves]

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

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

[suresh ds]

Fine. vCont is properly implemented and most of the things are working fine.
I've a query with single step.
Let's say there are four threads, 1,2,3,4.
Sometimes when I single step, I get a packet from gdb as "vCont;s:1;c".
Accordingly, I insert a break at the next address, and continue all.

1)

(i) Now, even before thread 1 hits the break at the next address, the other thread(s) may hit some other breakpoint and report that. In this case, the single step is not yet 
reached (and therefore not removed). A further continue will make all run, and then thread 1 may hit this single step break, remove it and report it to gdb. What this all means
 is, gdb may get the single step status after quite some time and not immediately after one does "step". Is this OK ?

(ii) There is also another possibility. Some other thread may hit this single step breakpoint, remove the breakpoint and report it than the actual thread 1, which is supposed 
to hit, remove it and report it. If this happens, then the actuaI thread 1 which is supposed to single step will not be single stepped. Is this way of implementation OK ?

2) Another way is, even if other threads hit some other breakpoint or hit this single step breakpoint itself, they do not report it and wait for thread 1 to hit the single step
 and report it. Is this the way to be implemented ?

Expecting your reply.

Thanks,
Suresh


----- Original Message -----
From: "Pedro Alves" 
To: "suresh ds" 
Cc: gdb@sourceware.org
Subject: Re: Behaviour of default all-stop mode -- Why no one has replied ?
Date: Mon, 6 Jul 2009 18:04:19 +0100


On Monday 06 July 2009 15:21:04, suresh ds wrote:
> After some trial and error, I observed that "vCont;c" indicates 
> that 'c'ontinue should be applied to all the threads that do not 
> have any default action specified. Actually, gdb documentation 
> could have been clearer; I read it a few times, tried out a few 
> times, only then understood the vCont behaviour. I saw your mail 
> later with your explanation of vCont which confirms my 
> understanding is correct. Well, anyway, vCont is implemented and 
> things are working fine. But I have a new issue here, given below:
>


> 1) Does gdb support threads with shared text ?

Yes.

> It is common to see different threads calling the same function 
> in which case the function becomes shared code for those threads. 
> Any specific option has to be turned on (in gdb)?

No.

>
> 2) I've mapped gdb threads to hardware threads in a 
> multi-processor MIPS SoC and these hardware threads share the 
> text. Theoritically, this is same as a function shared by 
> different software threads. I've pasted the log below:

>
> (gdb)target remote :
> Remote debugging using :
> Sending packet: $qSupported#37...Ack
> Packet received: Packet qSupported (supported-packets) is NOT supported
> Sending packet: $g#67...Ack
> Packet received: 
> 0000000000000000000000005000000100000000000000a000000000000000100000000000000001000000000087000000000000000000b0ffffffff900ddeed00000000018066ac00000000018066f8ffffffff800b40000000000001806868000000000180676800000000000000010000000000871704000000000087172400000000018068780000000000800000ffffffff800b40400000000000000004000000000080000000000000002d000000000000009538780000000000800000ffffffff800b4000000000000000000100000000000000000000000000000000000000000080ac5000000000008f2e800000000000000001000000000023a9fc000000005000000300000000015be680000000000124f80000000000008000000000000000008024000000000023757800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> Sending packet: $?#3f...Ack
> Packet received: T00thread:4;
> Sending packet: $Hc-1#09...Ack
> Packet received: OK
> Sending packet: $qC#b4...Ack
> Packet received: QC 4
> Sending packet: $qOffsets#4b...Ack
> Packet received: Text=0;Data=0;Bss=0
> [New Thread 4]
> Sending packet: $g#67...Ack
> Packet received: 
> 0000000000000000000000005000000100000000000000a000000000000000100000000000000001000000000087000000000000000000b0ffffffff900ddeed00000000018066ac00000000018066f8ffffffff800b40000000000001806868000000000180676800000000000000010000000000871704000000000087172400000000018068780000000000800000ffffffff800b40400000000000000004000000000080000000000000002d000000000000009538780000000000800000ffffffff800b4000000000000000000100000000000000000000000000000000000000000080ac5000000000008f2e800000000000000001000000000023a9fc000000005000000300000000015be680000000000124f80000000000008000000000000000008024000000000023757800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> 0x00237578 in gdb_break ()
>     at blah..blah..
> 85      blah..blah..
>         in blah..blah..
> Sending packet: $qSymbol::#5b...Ack
> Packet received: Packet qSymbol (symbol-lookup) is NOT supported
> (gdb)b fun
> Breakpoint 1 at 0x200388: file debug_test.c, line 46.
> (gdb)c
> Continuing.
> Sending packet: $Z0,200388,4#4b...Ack
> Packet received: OK
> Packet Z0 (software-breakpoint) is supported
> Sending packet: $vCont?#49...Ack
> Packet received: vCont;c;C;s;S;t;T
> Packet vCont (verbose-resume) is supported
> Sending packet: $vCont;c#a8...Ack
> Packet received: T05thread:7;
> [New Thread 7]
> Sending packet: $g#67...Ack
> Packet received: 
> 000000000000000000000000500000010000000000802c54ffffffffffffffff000000000000000000000000008f2fe000000000008f2fe8000000000000000000000000008000000000000000000001ffffffff800b4000000000000180686800000000018067680000000000000001000000000087170700000000008717270000000000000620ffffffff8c2626880000000000980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000000000030c8ffffffff800b4000000000000000000000000000000000000000000000000000000000000080ac5000000000008f2f3800000000000000000000000000200720000000005000000300000000015be680000000000124f80000810d688c26ce100000000000008024000000000020038800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> Sending packet: $g#67...Ack
> Packet received: 
> 000000000000000000000000500000010000000000802c54ffffffffffffffff000000000000000000000000008f2fe000000000008f2fe8000000000000000000000000008000000000000000000001ffffffff800b4000000000000180686800000000018067680000000000000001000000000087170700000000008717270000000000000620ffffffff8c2626880000000000980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000000000030c8ffffffff800b4000000000000000000000000000000000000000000000000000000000000080ac5000000000008f2f3800000000000000000000000000200720000000005000000300000000015be680000000000124f80000810d688c26ce100000000000008024000000000020038800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> [Switching to Thread 7]
> Sending packet: $z0,200388,4#6b...Ack
> Packet received: OK
>
> Breakpoint 1, fun () at debug_test.c:46
> 46      debug_test.c: No such file or directory.
>         in debug_test.c
> (gdb)c
> Continuing.
> Sending packet: $vCont;s:7#29...Ack
> Packet received: T05thread:7;
> Sending packet: $g#67...Ack
> Packet received: 
> 000000000000000000000000500000010000000000000002ffffffffffffffff000000000000000000000000008f2fe000000000008f2fe8000000000000000000000000008000000000000000000001ffffffff800b4000000000000180686800000000018067680000000000000001000000000087170700000000008717270000000000000620ffffffff8c2626880000000000980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000000000030c8ffffffff800b4000000000000000000000000000000000000000000000000000000000000080ac5000000000008f2f3800000000000000000000000000200720000000005000000300000000015be680000000000124f80000810d688c26ce100000000000008024000000000020038c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> Sending packet: $Z0,200388,4#4b...Ack
> Packet received: OK
> Sending packet: $vCont;c#a8...Ack
> Packet received: T05thread:7;
> Sending packet: $g#67...Ack
> Packet received: 
> 000000000000000000000000500000000000000050000001000000000000000b000000000000000b0000000000800398000000000000000a000000000000000100000000008000000000000000000001ffffffffbef1400000000000008f26b400000000008e07600000000000800000ffffffffffffffff00000000000000010000000000800000ffffffff8c2626880000000000980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000000000030c8000000000000000700000000000000010000000b00000000002cedf000000000000000000080ac5000000000008f2f3800000000000000000000000000200720000000005000000300000000015be680000000000124f800ffffffff8c145b880000000000008024000000000020038800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> Sending packet: $z0,200388,4#6b...Ack
> Packet received: OK
>
> Breakpoint 1, fun () at debug_test.c:46
> 46      in debug_test.c
> (gdb)info b
> Num     Type           Disp Enb Address    What
> 1       breakpoint     keep y   0x00200388 in fun at debug_test.c:46
>         breakpoint already hit 2 times
>
> <=======================================================================>
>
> I want to point out a few things. Here, four threads are running, 
> 4,5,6,7. Thread 7 hits the breakpoint and stops other threads 
> too; gdb also acknowledges this by typing "[Switching to Thread 
> 7]". A further continue gives rise to the foll. sequence (and my 
> comments are intersperced):
>
> (rmios-gdb)c
> Continuing.
> Sending packet: $vCont;s:7#29...Ack
> Packet received: T05thread:7;
>
> <==> At this point, gdb makes Thread 7 to step while indicating 
> nothing for the other threads
>
> Sending packet: $g#67...Ack
> Packet received: blah...blah..
> Sending packet: $Z0,200388,4#4b...Ack
> Packet received: OK
>
> <==> Once Thread 7 single steps, it inserts the breakpoint; Note 
> that other threads have not yet moved, but the breakpoint is 
> already inserted back !!
>
> Sending packet: $vCont;c#a8...Ack
> Packet received: T05thread:7;
>
> <==> Now, gdb makes all threads to continue. But this only makes 
> Thread 7 to continue and other threads are still at the same 
> point, because they came out of exception, and tried to execute 
> the same PC which has the address with breakpoint already 
> inserted back, so they hit the break again without really 
> proceeding.

So now would be a good time to report one of those threads has 
having hit the breakpoint.  Remember that events are serialized to 
GDB.

> Since Thread 7 has already single-stepped, it does not see this 
> break (which it itself inserted), proceeds further, later hits 
> this break again (as the code is in a loop).

This depends on your stub and OS scheduler.  If another thread had 
hit the same breakpoint, then by all means, report that instead.

>
> Ideally, the sequence should have been something like this:
> Sending packet: $vCont;s#29...Ack
> Packet received: blah...blah...
> Sending packet: $Z0,200388,4#4b...Ack
> Packet received: OK
> Sending packet: $g#67...Ack
> Packet received: blah...blah..
> Sending packet: $vCont;c#a8...Ack
> Packet received: T05thread:7;
>
> This will ensure that all threads have single-stepped once, then 
> the break can be inserted and the threads can be proceeded.

Not.  Remember that events are serialized to GDB.  From GDB's and 
the users perspective, the other
threads still haven't reported the breakpoint hit.

>
> Is this a bug in gdb ?

No.

> Is this the default behaviour of gdb, and it is left to the stub 
> to find some workaround for this ??

Yes, and no, but not really a workaround.

> Is there any option which can make this happen cleanly ?

No.  Depends on what you call cleanly though.

> If this is how gdb behaves, then other threads won't proceed at 
> all and just keep hitting the break again and again.

Have the stub report that to GDB.  Eventually the user types enough 
"continue"s to
move all threads passed the breakpoint.  If the user is only 
interested in being
reported of a breakpoint hits in a specific thread, she can set a 
"thread specific breakpoint"
instead.  "break foofunc thread 4", for example.

> Note that the above problem occurs because the threads share the 
> code (text). If they indeed are running different texts, then 
> this problem would not arise at all, which makes me think, does 
> gdb support threads with shared text, in the first place ?

Threads that do not share text is what would be modelled with
multiple process/address-space support, which GDB is only now beginning
to understand.  GDB has been assuming threads share text ever since
multithreading support was added to GDB.

> Please reply.

Ok.

--
Pedro Alves


-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com

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

[Pedro Alves]

Em Monday 20 July 2009 11:50:23, suresh ds escreveu:
> Fine. vCont is properly implemented and most of the things are working fine.
> I've a query with single step.
> Let's say there are four threads, 1,2,3,4.
> Sometimes when I single step, I get a packet from gdb as "vCont;s:1;c".
> Accordingly, I insert a break at the next address, and continue all.
> 
> 1)
> 
> (i) Now, even before thread 1 hits the break at the next address, the other thread(s) may hit some other breakpoint and report that. In this case, the single step is not yet 
> reached (and therefore not removed). A further continue will make all run, and then thread 1 may hit this single step break, remove it and report it to gdb. What this all means
>  is, gdb may get the single step status after quite some time and not immediately after one does "step". Is this OK ?

Take this sequence:

 1. --> vCont;s:1;c
 2. <-- T05 thread:2
 3. --> vCont;c

In this case, point 3 told thread 1 to continue, so any previous step
request to thread 1 is cancelled.  What is means is that the last
command applied to a thread is what counts.  Even this could happen:

 1. --> vCont;s:1;c
 2. <-- T05 thread:2
 3. --> <change PC of thread 1 to point somewhere else>
 4. --> vCont;s:1

Notice that the step in point 4 is now done at a different PC
from point 1.  Again, a new command to thread 1 cancelled a
previous command to thread 1. 

(warning: older GDB's didn't behave correctly in this use case)

> (ii) There is also another possibility. Some other thread may hit this single step breakpoint, remove the breakpoint and report it than the actual thread 1, which is supposed 
> to hit, remove it and report it. If this happens, then the actuaI thread 1 which is supposed to single step will not be single stepped. Is this way of implementation OK ?

No, it is not.  GDB would report a SIGTRAP to the user, as it
had no idea why did the thread stop.  And then again, neither would
the user know why did the thread stop if it didn't tell it to.  It
would be a confusing behaviour.  If you want to implement software single
stepping yourself, then you need to make sure that GDB doesn't see that
other threads can hit that thread-1-specific-internal-detail-to-your-stub
breakpoint.  It's as if you need to make GDB believe that your architecture
supports hardware single-stepping.

> 2) Another way is, even if other threads hit some other breakpoint or hit this single step breakpoint itself, they do not report it and wait for thread 1 to hit the single step
>  and report it. Is this the way to be implemented ?

That's one way.  Another way is to make the thread that hit the
other-thread's-step-breakpoint "step over" the breakpoint (remove breaks; step
*only* that thread, leaving others stopped; reinsert breaks; resume threads
again, going on waiting for the right thread to reach the step
breakpoint) --- this is an implementation that avoids more than one
level deep nested software single stepping, and is what GDB implements itself
(see src/gdb/infrun.c and look around for stepping_past_singlestep_breakpoint).
You could even go crazy and support a fully nested algorithm, by *only* removing
the step-breakpoint that the thread is trying to step over, and resume all
threads that GDB asked to be running *except* the thread that *was supposed*
to hit that step-breakpoint (otherwise, that thread may well miss its step break).
Your version would be what I'd call a 0-level nesting implementation; gdb's a
1-level nesting, the latter a more complicated N-level nesting version.

-- 
Pedro Alves

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

[suresh ds]

After some trial and error, I observed that "vCont;c" indicates that 'c'ontinue should be applied to all the threads that do not have any default action specified. Actually, gdb documentation could have been clearer; I read it a few times, tried out a few times, only then understood the vCont behaviour. I saw your mail later with your explanation of vCont which confirms my understanding is correct. Well, anyway, vCont is implemented and things are working fine. But I have a new issue here, given below:

1) Does gdb support threads with shared text ? It is common to see different threads calling the same function in which case the function becomes shared code for those threads. Any specific option has to be turned on (in gdb)?

2) I've mapped gdb threads to hardware threads in a multi-processor MIPS SoC and these hardware threads share the text. Theoritically, this is same as a function shared by different software threads. I've pasted the log below:

(gdb)target remote <ipaddr>:<port>
Remote debugging using <ipaddr>:<port>
Sending packet: $qSupported#37...Ack
Packet received: 
Packet qSupported (supported-packets) is NOT supported
Sending packet: $g#67...Ack
Packet received: 0000000000000000000000005000000100000000000000a000000000000000100000000000000001000000000087000000000000000000b0ffffffff900ddeed00000000018066ac00000000018066f8ffffffff800b40000000000001806868000000000180676800000000000000010000000000871704000000000087172400000000018068780000000000800000ffffffff800b40400000000000000004000000000080000000000000002d000000000000009538780000000000800000ffffffff800b4000000000000000000100000000000000000000000000000000000000000080ac5000000000008f2e800000000000000001000000000023a9fc000000005000000300000000015be680000000000124f80000000000008000000000000000008024000000000023757800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Sending packet: $?#3f...Ack
Packet received: T00thread:4;
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received: QC 4
Sending packet: $qOffsets#4b...Ack
Packet received: Text=0;Data=0;Bss=0
[New Thread 4]
Sending packet: $g#67...Ack
Packet received: 0000000000000000000000005000000100000000000000a000000000000000100000000000000001000000000087000000000000000000b0ffffffff900ddeed00000000018066ac00000000018066f8ffffffff800b40000000000001806868000000000180676800000000000000010000000000871704000000000087172400000000018068780000000000800000ffffffff800b40400000000000000004000000000080000000000000002d000000000000009538780000000000800000ffffffff800b4000000000000000000100000000000000000000000000000000000000000080ac5000000000008f2e800000000000000001000000000023a9fc000000005000000300000000015be680000000000124f80000000000008000000000000000008024000000000023757800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0x00237578 in gdb_break ()
    at blah..blah..
85      blah..blah..
        in blah..blah..
Sending packet: $qSymbol::#5b...Ack
Packet received: 
Packet qSymbol (symbol-lookup) is NOT supported
(gdb)b fun
Breakpoint 1 at 0x200388: file debug_test.c, line 46.
(gdb)c
Continuing.
Sending packet: $Z0,200388,4#4b...Ack
Packet received: OK
Packet Z0 (software-breakpoint) is supported
Sending packet: $vCont?#49...Ack
Packet received: vCont;c;C;s;S;t;T
Packet vCont (verbose-resume) is supported
Sending packet: $vCont;c#a8...Ack
Packet received: T05thread:7;
[New Thread 7]
Sending packet: $g#67...Ack
Packet received: 000000000000000000000000500000010000000000802c54ffffffffffffffff000000000000000000000000008f2fe000000000008f2fe8000000000000000000000000008000000000000000000001ffffffff800b4000000000000180686800000000018067680000000000000001000000000087170700000000008717270000000000000620ffffffff8c2626880000000000980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000000000030c8ffffffff800b4000000000000000000000000000000000000000000000000000000000000080ac5000000000008f2f3800000000000000000000000000200720000000005000000300000000015be680000000000124f80000810d688c26ce100000000000008024000000000020038800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Sending packet: $g#67...Ack
Packet received: 000000000000000000000000500000010000000000802c54ffffffffffffffff000000000000000000000000008f2fe000000000008f2fe8000000000000000000000000008000000000000000000001ffffffff800b4000000000000180686800000000018067680000000000000001000000000087170700000000008717270000000000000620ffffffff8c2626880000000000980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000000000030c8ffffffff800b4000000000000000000000000000000000000000000000000000000000000080ac5000000000008f2f3800000000000000000000000000200720000000005000000300000000015be680000000000124f80000810d688c26ce100000000000008024000000000020038800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[Switching to Thread 7]
Sending packet: $z0,200388,4#6b...Ack
Packet received: OK

Breakpoint 1, fun () at debug_test.c:46
46      debug_test.c: No such file or directory.
        in debug_test.c
(gdb)c
Continuing.
Sending packet: $vCont;s:7#29...Ack
Packet received: T05thread:7;
Sending packet: $g#67...Ack
Packet received: 000000000000000000000000500000010000000000000002ffffffffffffffff000000000000000000000000008f2fe000000000008f2fe8000000000000000000000000008000000000000000000001ffffffff800b4000000000000180686800000000018067680000000000000001000000000087170700000000008717270000000000000620ffffffff8c2626880000000000980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000000000030c8ffffffff800b4000000000000000000000000000000000000000000000000000000000000080ac5000000000008f2f3800000000000000000000000000200720000000005000000300000000015be680000000000124f80000810d688c26ce100000000000008024000000000020038c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Sending packet: $Z0,200388,4#4b...Ack
Packet received: OK
Sending packet: $vCont;c#a8...Ack
Packet received: T05thread:7;
Sending packet: $g#67...Ack
Packet received: 000000000000000000000000500000000000000050000001000000000000000b000000000000000b0000000000800398000000000000000a000000000000000100000000008000000000000000000001ffffffffbef1400000000000008f26b400000000008e07600000000000800000ffffffffffffffff00000000000000010000000000800000ffffffff8c2626880000000000980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000000000030c8000000000000000700000000000000010000000b00000000002cedf000000000000000000080ac5000000000008f2f3800000000000000000000000000200720000000005000000300000000015be680000000000124f800ffffffff8c145b880000000000008024000000000020038800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Sending packet: $z0,200388,4#6b...Ack
Packet received: OK

Breakpoint 1, fun () at debug_test.c:46
46      in debug_test.c
(gdb)info b
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x00200388 in fun at debug_test.c:46
        breakpoint already hit 2 times

<=======================================================================>

I want to point out a few things. Here, four threads are running, 4,5,6,7. Thread 7 hits the breakpoint and stops other threads too; gdb also acknowledges this by typing "[Switching to Thread 7]". A further continue gives rise to the foll. sequence (and my comments are intersperced):

(rmios-gdb)c
Continuing.
Sending packet: $vCont;s:7#29...Ack
Packet received: T05thread:7;

<==> At this point, gdb makes Thread 7 to step while indicating nothing for the other threads

Sending packet: $g#67...Ack
Packet received: blah...blah..
Sending packet: $Z0,200388,4#4b...Ack
Packet received: OK

<==> Once Thread 7 single steps, it inserts the breakpoint; Note that other threads have not yet moved, but the breakpoint is already inserted back !!

Sending packet: $vCont;c#a8...Ack
Packet received: T05thread:7;

<==> Now, gdb makes all threads to continue. But this only makes Thread 7 to continue and other threads are still at the same point, because they came out of exception, and tried to execute the same PC which has the address with breakpoint already inserted back, so they hit the break again without really proceeding. Since Thread 7 has already single-stepped, it does not see this break (which it itself inserted), proceeds further, later hits this break again (as the code is in a loop).

Ideally, the sequence should have been something like this:
Sending packet: $vCont;s#29...Ack
Packet received: blah...blah...
Sending packet: $Z0,200388,4#4b...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received: blah...blah..
Sending packet: $vCont;c#a8...Ack
Packet received: T05thread:7;

This will ensure that all threads have single-stepped once, then the break can be inserted and the threads can be proceeded.

Is this a bug in gdb ?
Is this the default behaviour of gdb, and it is left to the stub to find some workaround for this ??
Is there any option which can make this happen cleanly ?
If this is how gdb behaves, then other threads won't proceed at all and just keep hitting the break again and again.
Note that the above problem occurs because the threads share the code (text). If they indeed are running different texts, then this problem would not arise at all, which makes me think, does gdb support threads with shared text, in the first place ?

Please reply.

Thanks,
Suresh




-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com

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

[Pedro Alves]

On Monday 06 July 2009 15:21:04, suresh ds wrote:
> After some trial and error, I observed that "vCont;c" indicates that 'c'ontinue should be applied to all the threads that do not have any default action specified. Actually, gdb documentation could have been clearer; I read it a few times, tried out a few times, only then understood the vCont behaviour. I saw your mail later with your explanation of vCont which confirms my understanding is correct. Well, anyway, vCont is implemented and things are working fine. But I have a new issue here, given below:
> 


> 1) Does gdb support threads with shared text ? 

Yes.

> It is common to see different threads calling the same function in which case the function becomes shared code for those threads. Any specific option has to be turned on (in gdb)? 

No.

> 
> 2) I've mapped gdb threads to hardware threads in a multi-processor MIPS SoC and these hardware threads share the text. Theoritically, this is same as a function shared by different software threads. I've pasted the log below:

> 
> (gdb)target remote <ipaddr>:<port>
> Remote debugging using <ipaddr>:<port>
> Sending packet: $qSupported#37...Ack
> Packet received: 
> Packet qSupported (supported-packets) is NOT supported
> Sending packet: $g#67...Ack
> Packet received: 0000000000000000000000005000000100000000000000a000000000000000100000000000000001000000000087000000000000000000b0ffffffff900ddeed00000000018066ac00000000018066f8ffffffff800b40000000000001806868000000000180676800000000000000010000000000871704000000000087172400000000018068780000000000800000ffffffff800b40400000000000000004000000000080000000000000002d000000000000009538780000000000800000ffffffff800b4000000000000000000100000000000000000000000000000000000000000080ac5000000000008f2e800000000000000001000000000023a9fc000000005000000300000000015be680000000000124f80000000000008000000000000000008024000000000023757800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> Sending packet: $?#3f...Ack
> Packet received: T00thread:4;
> Sending packet: $Hc-1#09...Ack
> Packet received: OK
> Sending packet: $qC#b4...Ack
> Packet received: QC 4
> Sending packet: $qOffsets#4b...Ack
> Packet received: Text=0;Data=0;Bss=0
> [New Thread 4]
> Sending packet: $g#67...Ack
> Packet received: 0000000000000000000000005000000100000000000000a000000000000000100000000000000001000000000087000000000000000000b0ffffffff900ddeed00000000018066ac00000000018066f8ffffffff800b40000000000001806868000000000180676800000000000000010000000000871704000000000087172400000000018068780000000000800000ffffffff800b40400000000000000004000000000080000000000000002d000000000000009538780000000000800000ffffffff800b4000000000000000000100000000000000000000000000000000000000000080ac5000000000008f2e800000000000000001000000000023a9fc000000005000000300000000015be680000000000124f80000000000008000000000000000008024000000000023757800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> 0x00237578 in gdb_break ()
>     at blah..blah..
> 85      blah..blah..
>         in blah..blah..
> Sending packet: $qSymbol::#5b...Ack
> Packet received: 
> Packet qSymbol (symbol-lookup) is NOT supported
> (gdb)b fun
> Breakpoint 1 at 0x200388: file debug_test.c, line 46.
> (gdb)c
> Continuing.
> Sending packet: $Z0,200388,4#4b...Ack
> Packet received: OK
> Packet Z0 (software-breakpoint) is supported
> Sending packet: $vCont?#49...Ack
> Packet received: vCont;c;C;s;S;t;T
> Packet vCont (verbose-resume) is supported
> Sending packet: $vCont;c#a8...Ack
> Packet received: T05thread:7;
> [New Thread 7]
> Sending packet: $g#67...Ack
> Packet received: 000000000000000000000000500000010000000000802c54ffffffffffffffff000000000000000000000000008f2fe000000000008f2fe8000000000000000000000000008000000000000000000001ffffffff800b4000000000000180686800000000018067680000000000000001000000000087170700000000008717270000000000000620ffffffff8c2626880000000000980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000000000030c8ffffffff800b4000000000000000000000000000000000000000000000000000000000000080ac5000000000008f2f3800000000000000000000000000200720000000005000000300000000015be680000000000124f80000810d688c26ce100000000000008024000000000020038800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> Sending packet: $g#67...Ack
> Packet received: 000000000000000000000000500000010000000000802c54ffffffffffffffff000000000000000000000000008f2fe000000000008f2fe8000000000000000000000000008000000000000000000001ffffffff800b4000000000000180686800000000018067680000000000000001000000000087170700000000008717270000000000000620ffffffff8c2626880000000000980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000000000030c8ffffffff800b4000000000000000000000000000000000000000000000000000000000000080ac5000000000008f2f3800000000000000000000000000200720000000005000000300000000015be680000000000124f80000810d688c26ce100000000000008024000000000020038800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> [Switching to Thread 7]
> Sending packet: $z0,200388,4#6b...Ack
> Packet received: OK
> 
> Breakpoint 1, fun () at debug_test.c:46
> 46      debug_test.c: No such file or directory.
>         in debug_test.c
> (gdb)c
> Continuing.
> Sending packet: $vCont;s:7#29...Ack
> Packet received: T05thread:7;
> Sending packet: $g#67...Ack
> Packet received: 000000000000000000000000500000010000000000000002ffffffffffffffff000000000000000000000000008f2fe000000000008f2fe8000000000000000000000000008000000000000000000001ffffffff800b4000000000000180686800000000018067680000000000000001000000000087170700000000008717270000000000000620ffffffff8c2626880000000000980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000000000030c8ffffffff800b4000000000000000000000000000000000000000000000000000000000000080ac5000000000008f2f3800000000000000000000000000200720000000005000000300000000015be680000000000124f80000810d688c26ce100000000000008024000000000020038c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> Sending packet: $Z0,200388,4#4b...Ack
> Packet received: OK
> Sending packet: $vCont;c#a8...Ack
> Packet received: T05thread:7;
> Sending packet: $g#67...Ack
> Packet received: 000000000000000000000000500000000000000050000001000000000000000b000000000000000b0000000000800398000000000000000a000000000000000100000000008000000000000000000001ffffffffbef1400000000000008f26b400000000008e07600000000000800000ffffffffffffffff00000000000000010000000000800000ffffffff8c2626880000000000980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000000000030c8000000000000000700000000000000010000000b00000000002cedf000000000000000000080ac5000000000008f2f3800000000000000000000000000200720000000005000000300000000015be680000000000124f800ffffffff8c145b880000000000008024000000000020038800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> Sending packet: $z0,200388,4#6b...Ack
> Packet received: OK
> 
> Breakpoint 1, fun () at debug_test.c:46
> 46      in debug_test.c
> (gdb)info b
> Num     Type           Disp Enb Address    What
> 1       breakpoint     keep y   0x00200388 in fun at debug_test.c:46
>         breakpoint already hit 2 times
> 
> <=======================================================================>
> 
> I want to point out a few things. Here, four threads are running, 4,5,6,7. Thread 7 hits the breakpoint and stops other threads too; gdb also acknowledges this by typing "[Switching to Thread 7]". A further continue gives rise to the foll. sequence (and my comments are intersperced):
> 
> (rmios-gdb)c
> Continuing.
> Sending packet: $vCont;s:7#29...Ack
> Packet received: T05thread:7;
> 
> <==> At this point, gdb makes Thread 7 to step while indicating nothing for the other threads
> 
> Sending packet: $g#67...Ack
> Packet received: blah...blah..
> Sending packet: $Z0,200388,4#4b...Ack
> Packet received: OK
> 
> <==> Once Thread 7 single steps, it inserts the breakpoint; Note that other threads have not yet moved, but the breakpoint is already inserted back !!
> 
> Sending packet: $vCont;c#a8...Ack
> Packet received: T05thread:7;
> 
> <==> Now, gdb makes all threads to continue. But this only makes Thread 7 to continue and other threads are still at the same point, because they came out of exception, and tried to execute the same PC which has the address with breakpoint already inserted back, so they hit the break again without really proceeding. 

So now would be a good time to report one of those threads has having hit the breakpoint.  Remember that events are serialized to GDB.

> Since Thread 7 has already single-stepped, it does not see this break (which it itself inserted), proceeds further, later hits this break again (as the code is in a loop). 

This depends on your stub and OS scheduler.  If another thread had hit the same breakpoint, then by all means, report that instead.

> 
> Ideally, the sequence should have been something like this:
> Sending packet: $vCont;s#29...Ack
> Packet received: blah...blah...
> Sending packet: $Z0,200388,4#4b...Ack
> Packet received: OK
> Sending packet: $g#67...Ack
> Packet received: blah...blah..
> Sending packet: $vCont;c#a8...Ack
> Packet received: T05thread:7;
> 
> This will ensure that all threads have single-stepped once, then the break can be inserted and the threads can be proceeded.

Not.  Remember that events are serialized to GDB.  From GDB's and the users perspective, the other
threads still haven't reported the breakpoint hit.

> 
> Is this a bug in gdb ?

No.

> Is this the default behaviour of gdb, and it is left to the stub to find some workaround for this ??

Yes, and no, but not really a workaround.

> Is there any option which can make this happen cleanly ?

No.  Depends on what you call cleanly though.

> If this is how gdb behaves, then other threads won't proceed at all and just keep hitting the break again and again.

Have the stub report that to GDB.  Eventually the user types enough "continue"s to
move all threads passed the breakpoint.  If the user is only interested in being
reported of a breakpoint hits in a specific thread, she can set a "thread specific breakpoint"
instead.  "break foofunc thread 4", for example.

> Note that the above problem occurs because the threads share the code (text). If they indeed are running different texts, then this problem would not arise at all, which makes me think, does gdb support threads with shared text, in the first place ?

Threads that do not share text is what would be modelled with
multiple process/address-space support, which GDB is only now beginning
to understand.  GDB has been assuming threads share text ever since
multithreading support was added to GDB.

> Please reply.

Ok.

-- 
Pedro Alves

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

[suresh ds]

Thanks Daniel.
I'm still expecting answers for my other queries.
1) When I continue, gdb sends packet only to resume one (current) thread. How to make gdb send packets to resume other threads ?
Even if I 'switch' to other thread, and continue, it still keeps sending packets only to the previously set thread.

2) Through 'Thread apply' or Thread-specific breakpoints' also, I'm not able to make gdb send packets to resume threads.

How to achieve this ?


Thanks,
Suresh


----- Original Message -----
From: "Daniel Jacobowitz" 
To: "suresh ds" 
Cc: "Pedro Alves" , gdb@sourceware.org
Subject: Re: Behaviour of default all-stop mode -- Why no one has replied ?
Date: Mon, 15 Jun 2009 11:20:10 -0400


On Mon, Jun 15, 2009 at 10:09:44AM -0500, suresh ds wrote:
> Then I switched to thread 1. I really a have a big requirement from
> the gdb developers here. Once I switch to a thread, ideally I expect
> all further commands to apply only to that thread; It makes life
> simple, isn't it ?

This is non-stop mode.  You need a GDB that supports non-stop mode for
your processor in order to do this.

GDB 6.8 doesn't support non-stop at all.  GDB in CVS doesn't support
non-stop for MIPS yet, I believe.

--
Daniel Jacobowitz
CodeSourcery


-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com

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

[Daniel Jacobowitz]

On Mon, Jun 15, 2009 at 10:36:58AM -0500, suresh ds wrote:
> Thanks Daniel.
> I'm still expecting answers for my other queries.
> 1) When I continue, gdb sends packet only to resume one (current) thread. How to make gdb send packets to resume other threads ?
> Even if I 'switch' to other thread, and continue, it still keeps sending packets only to the previously set thread.
> 
> 2) Through 'Thread apply' or Thread-specific breakpoints' also, I'm not able to make gdb send packets to resume threads.
> 
> How to achieve this ?

I don't know, but you may want to investigate the scheduler-locking
setting.  Also, don't be fooled by GDB's behavior when there is a
breakpoint at the current address; that's a special case that trips up
a lot of people.  Look at the following vCont after GDB has navigated
off the breakpoint.

-- 
Daniel Jacobowitz
CodeSourcery

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

[suresh ds]

Thanks for the reply.
I think I've to explain a bit more here to indicate what problems I face and how I'm stuck.

I'm developing a stub for a multi-core mips-based processor, with each core containing a certain no. of hardware threads. Assuming 'n' core, with each core consisting of 'm' threads, totally it'll be n*m threads. The host is gdb-6.8 cross-compiled for mips64.

Each of these n*m threads can run any image. These images, will get compiled along with the stub (which means each of these n*m threads will run an image which consists of application + stub). The stub is a kind of library which the images link to while getting compiled. I don't have the luxury of keeping one thread aside only for the stub.
When these images come up, they execute a break instruction (as recommended by gdb) and go into exception mode waiting for gdb commands. When gdb connects, it connects to a default (hardware) thread, say thread 1. Of course, gdb does not know anything about hardware threads, I'm mapping the gdb's software threads to hardware threads in the chip. (This is the way in general, multi-core debugging is achieved in gdb since gdb is not yet multi-core aware...).

As gdb connects to the default hardware thread 1 (shortly, ht1), the stub sitting in ht1 responds to queries (including the '?' packet). At this stage, note that all hardware threads are stopped. When gdb queries with a '?' to ht1, should ht1 apart from sending its status, also report the status of other hardware threads, something like "$T05;thread:1;thread:2;blah blah". It is another matter that whether I reported initially the status of all the hardware threads or not, didn't solve the problem. Initially, I tried only "$T05:thread:1", which means only that default thread sent its status. Then I did "info threads" to make gdb aware that there are other threads too. Then I switched to thread 1. I really a have a big requirement from the gdb developers here. Once I switch to a thread, ideally I expect all further commands to apply only to that thread; It makes life simple, isn't it ? (Of course, I tried "thread apply", it didn't work as expected. I don't know if this is also post-6.8 !!).Here, switching to a thread really doesn't make you switch to that thread. Because if you step or continue, it can still step or continue other threads. Even an "info reg" is not guaranteed to fetch only THAT thread's registers. With this background, let's go into the log where my comments also are given at appropriate places prefixed with a ==>>

(gdb)target remote 10.7.8.68:5000
Remote debugging using 10.7.8.68:5000
Sending packet: $qSupported#37...Ack
Packet received: 
Packet qSupported (supported-packets) is NOT supported
Sending packet: $g#67...Ack
Packet received: 00000000000000000000000050000001ffffffff800b4000ffffffff800b40200000000000000001000000000080000000000000018066a80000000000000001000000000180683800000000018067280000000000000001ffffffff800b00000000000000000001000000000087170c000000000000006000000000000000700000000000000010000000000087172cffffffff900ddeed0000000000000004000000000080000000000000002d000000000000009538780000000000800000ffffffff800b4000ffffffff800b404000000000000000000000000000000000000000000080ac5000000000008f2e800000000000000001000000000023b2fc0000000050000003000000000121eac00000000000f4240000000000008000000000000000008024000000000023741000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Sending packet: $?#3f...Ack
Packet received: T05thread:4;thread:5;thread:6;

==>> Well, the stub sitting on thread 4 (default hardware thread) corresponds to gdb here. It also sends the status of other (hardware) threads. Initially, I made thread 4 pass only its status as "$T05thread:4", but no difference.

Sending packet: $Hc-1#09...Ack

==>> Here, gdb asks to resume all threads, '-1' indicating 'all threads'. But I don't resume here, all the threads are still in stopped state. If I resume all the threads here in fact, I don't think it'll matter ?

Packet received: OK
Sending packet: $qC#b4...Ack
Packet received: QC 4
Sending packet: $qOffsets#4b...Ack
Packet received: Text=0;Data=0;Bss=0
[New Thread 4]
[New Thread 5]
[New Thread 6]
Sending packet: $g#67...Ack
Packet received: 00000000000000000000000050000001ffffffff800b4000ffffffff800b40200000000000000001000000000080000000000000018066a80000000000000001000000000180683800000000018067280000000000000001ffffffff800b00000000000000000001000000000087170c000000000000006000000000000000700000000000000010000000000087172cffffffff900ddeed0000000000000004000000000080000000000000002d000000000000009538780000000000800000ffffffff800b4000ffffffff800b404000000000000000000000000000000000000000000080ac5000000000008f2e800000000000000001000000000023b2fc0000000050000003000000000121eac00000000000f4240000000000008000000000000000008024000000000023741000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Sending packet: $g#67...Ack
Packet received: 00000000000000000000000050000001ffffffff800b4000ffffffff800b40200000000000000001000000000080000000000000018066a80000000000000001000000000180683800000000018067280000000000000001ffffffff800b00000000000000000001000000000087170c000000000000006000000000000000700000000000000010000000000087172cffffffff900ddeed0000000000000004000000000080000000000000002d000000000000009538780000000000800000ffffffff800b4000ffffffff800b404000000000000000000000000000000000000000000080ac5000000000008f2e800000000000000001000000000023b2fc0000000050000003000000000121eac00000000000f4240000000000008000000000000000008024000000000023741000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[Switching to Thread 6]

==>> The stub on ht4 (hardware thread 4), has reported three threads, 4, 5, and 6 to gdb; And, gdb has switched to the last reported thread here.

0x00237410 in gdb_break ()
    at blah blah....
123     
        
Sending packet: $qSymbol::#5b...Ack
Packet received: 
Packet qSymbol (symbol-lookup) is NOT supported
(gdb)info threads
Sending packet: $T00000006#da...Ack
Packet received: OK
Sending packet: $T00000005#d9...Ack
Packet received: OK
Sending packet: $T00000004#d8...Ack
Packet received: OK
Sending packet: $qfThreadInfo#bb...Ack
Packet received: m 4,5,6,l
Sending packet: $qsThreadInfo#c8...Ack
Packet received: l
Sending packet: $qThreadExtraInfo,6#bb...Ack
Packet received: 72756e6e696e67
* 3 Thread 6 (running)  0x00237410 in gdb_break ()
    at blah blah...
Sending packet: $qThreadExtraInfo,5#ba...Ack
Packet received: 72756e6e696e67
Sending packet: $Hg5#e4...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received: 00000000000000000000000050000001ffffffff800b4000ffffffff800b40200000000000000001000000000080000000000000018066a80000000000000001000000000180683c00000000018067280000000000000001ffffffff800b00000000000000000001000000000087170d000000000000000000000000000000200000000000000020000000000087172dffffffff900ddeed0000000000000005000000000080000000000000002d00000000000000953a780000000000800000ffffffff800b4000ffffffff800b404000000000000000000000000000000000000000000080ac5000000000008f2e800000000000000001000000000023b2fc0000000050000003000000000121eac00000000000f4240000000000008000000000000000008024000000000023741000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
  2 Thread 5 (running)  0x00237410 in gdb_break ()
    at blah blah...
Sending packet: $qThreadExtraInfo,4#b9...Ack
Packet received: 72756e6e696e67
Sending packet: $Hg4#e3...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received: 00000000000000000000000050000001ffffffff800b4000ffffffff800b40200000000000000001000000000080000000000000018066a80000000000000001000000000180683800000000018067280000000000000001ffffffff800b00000000000000000001000000000087170c000000000000006000000000000000700000000000000010000000000087172cffffffff900ddeed0000000000000004000000000080000000000000002d000000000000009538780000000000800000ffffffff800b4000ffffffff800b404000000000000000000000000000000000000000000080ac5000000000008f2e800000000000000001000000000023b2fc0000000050000003000000000121eac00000000000f4240000000000008000000000000000008024000000000023741000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
  1 Thread 4 (running)  0x00237410 in gdb_break ()
    at blah blah...
Sending packet: $Hg6#e5...Ack
Packet received: OK
Sending packet: $g#67...Ack
Packet received: 00000000000000000000000050000001ffffffff800b4000ffffffff800b40200000000000000001000000000080000000000000018066a80000000000000001000000000180684000000000018067280000000000000001ffffffff800b00000000000000000001000000000087170e000000000000002000000000000000600000000000000040000000000087172effffffff900ddeed0000000000000006000000000080000000000000002d00000000000000953c780000000000800000ffffffff800b4000ffffffff800b404000000000000000000000000000000000000000000080ac5000000000008f2e800000000000000001000000000023b2fc0000000050000003000000000121eac00000000000f4240000000000008000000000000000008024000000000023741000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

==>> At this point, gdb is made aware that there are three threads waiting to be debugged; Already, the presence of these threads were also indicated when the stub on the default thread sent the status of all the threads.

(rmios-gdb)c
Continuing.
Sending packet: $vCont?#49...Ack
Packet received: vCont;c;C;s;S;t;T
Packet vCont (verbose-resume) is supported
Sending packet: $vCont;c#a8...Ack

==>> In default all-stop mode, when you do continue, all threads should continue, correct ? According to our discussions so far (read mails below), gdb will indicate through vCont, which threads it wants to resume. But here, it does not indicate. So, which thread should I resume ? Actually, I resumed the default thread (4). Should the stub resume all the threads even though it has not received any thread no. ?

Now, this is without any breakpoints set. Even if I set a breakpoint and continue, it only continues the 'current' thread. I typically expect something like this from gdb. "$vCont;c:4;c:5;blahblah". After thread 4 hits the breakpoint, then I switch to some other thread,say 5, and continue, gdb still sends packets only to continue thread 4; Thread 5 does not move at all. In other words, switching to any thread does not make gdb to send packets in that thread context (which I've complained earlier).

I tried 'thread-specific breakpoints', and 'thread apply', but to no avail. Forget breakpoint setting; First of all, when I continue from one thread, why gdb is not issuing packets to resume all the threads? Is this not the expected behaviour in default all-stop mode ? In our earlier discussions, you have mentioned that that stub itself should not resume all the threads and that the gdb will indicate that through vCont packets, which is not happening here.

Please help.


Thanks,
Suresh



----- Original Message -----
From: "Pedro Alves" 
To: "suresh ds" 
Cc: gdb@sourceware.org
Subject: Re: Behaviour of default all-stop mode -- Why no one has replied ?
Date: Mon, 15 Jun 2009 12:01:43 +0100


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


-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com

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

[Daniel Jacobowitz]

On Mon, Jun 15, 2009 at 10:09:44AM -0500, suresh ds wrote:
> Then I switched to thread 1. I really a have a big requirement from
> the gdb developers here. Once I switch to a thread, ideally I expect
> all further commands to apply only to that thread; It makes life
> simple, isn't it ?

This is non-stop mode.  You need a GDB that supports non-stop mode for
your processor in order to do this.

GDB 6.8 doesn't support non-stop at all.  GDB in CVS doesn't support
non-stop for MIPS yet, I believe.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Pedro Alves]

On Monday 15 June 2009 16:09:44, suresh ds wrote:

> Packet received: T05thread:4;thread:5;thread:6;

I have a feeling that GDB will parse this and end up ignoring
the "thread4;thread5" part, as thread:6 will clobber whatever was
parsed as thread id before.  Implementing a stub means to pass to GDB
what GDB wants to, not what you might think you should pass.  Here,
you want only "T05thread:4", that's it.  In all-stop mode, events
have to be serialized to GDB, so, it doesn't really make sense to
pass more than one status.

> 
> ==>> Well, the stub sitting on thread 4 (default hardware thread) corresponds to gdb here. It also sends the status of other (hardware) threads. Initially, I made thread 4 pass only its status as "$T05thread:4", but no difference.
> 
> Sending packet: $Hc-1#09...Ack
> 
> ==>> Here, gdb asks to resume all threads, '-1' indicating 'all threads'. But I don't resume here, all the threads are still in stopped state. If I resume all the threads here in fact, I don't think it'll matter ?

Sure it does matter.  You're resuming the target when GDB
has *not* told you to.  'H' is, and I quote:

"Set thread for subsequent operations".  It just selects the threads,
doesn't resume them.  In any case, if you implement vCont, you won't
see GDB sending Hc appart from this initial one.  You can safely
ignore this, as the vCont packet is stateless.


> ==>> The stub on ht4 (hardware thread 4), has reported three threads, 4, 5, and 6 to gdb; And, gdb has switched to the last reported thread here.

Right, in all-stop mode, GDB always switches the general thread to
to the thread that reported the event, and (this is important) assumes that
the stub has also switched the general thread accordingly.

> ==>> At this point, gdb is made aware that there are three threads waiting to be debugged; 

> Already, the presence of these threads were also indicated when the stub on the default thread sent the status of all the threads. 

Well, you think it has, but it hasn't.  Those extra statuses are just ignored.

> 
> (rmios-gdb)c
> Continuing.
> Sending packet: $vCont?#49...Ack
> Packet received: vCont;c;C;s;S;t;T
> Packet vCont (verbose-resume) is supported
> Sending packet: $vCont;c#a8...Ack
> 
> ==>> In default all-stop mode, when you do continue, all threads should continue, correct ? According to our discussions so far (read mails below), gdb will indicate through vCont, which threads it wants to resume. But here, it does not indicate. So, which thread should I resume ? Actually, I resumed the default thread (4). Should the stub resume all the threads even though it has not received any thread no. ?

I already pointed out what should happen here.  Pasting again:

> `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;
>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 

So, "vCont;c" reads: action == 'c'ontinue; no thread-id specified, and no
other threads have a specific action specified --> means that
action "continue" is applied to all threads.

In other words:

 vCont;c --> continue all threads

 vCont;c:1 --> continue just thread 1

 vCont;s:1;c --> step thread 1, continue all others

 vCont;s:1 --> step thread 1, leaving all others stopped.

> 
> Now, this is without any breakpoints set. Even if I set a breakpoint and continue, it only continues the 'current' thread. I typically expect something like this from gdb. "$vCont;c:4;c:5;blahblah". 

How can you "typically" expect something from the protocol you're just
learning is mystifying to me.  ;-)

> After thread 4 hits the breakpoint, then I switch to some other thread,say 5, and continue, gdb still sends packets only to continue thread 4; Thread 5 does not move at all. In other words, switching to any thread does not make gdb to send packets in that thread context (which I've complained earlier). 
> 
> I tried 'thread-specific breakpoints', and 'thread apply', but to no avail. Forget breakpoint setting; First of all, when I continue from one thread, why gdb is not issuing packets to resume all the threads? Is this not the expected behaviour in default all-stop mode ? In our earlier discussions, you have mentioned that that stub itself should not resume all the threads and that the gdb will indicate that through vCont packets, which is not happening here.

It is.  You have to learn about the "(gdb) set scheduler-locking" setting
first to understand what GDB wants to resume by default.

(you also have the sources of GDB at your disposal.  You can
make use of it to your advantage!  src/gdb/remote.c is where all the
remote protocol action happens).

-- 
Pedro Alves

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

[suresh ds]

I'm re-posting my previous query. I need information on this urgently. Please reply.

The foll. are w.r.to remote debugging in gdb 6.8 cross-compiled for mips64.

In the default all-stop mode,

1) The document says, "whenever your program stops under GDB for any reason,all threads of execution stop, not just the current thread"
-- Here, the initiation is done by gdb or the (remote) stub should take care of this ?
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 ?

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.
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.
Ideally, what I expected is, gdb will take care of continuing all the  threads, something like this (assuming no breakpoints set in any of the threads ):

<gdb-thread1> continue
Sending packet: $Hc1#xx...Ack
Packet received: OK
Sending packet: $c#63...Ack
Sending packet: $Hc2#xx...Ack
Packet received: OK
Sending packet: $c#63...Ack
Sending packet: $Hc3#xx...Ack
Packet received: OK
Sending packet: $c#63...Ack

gdb can even do this in a simpler way, as just:
<gdb-thread1> continue
Sending packet: $Hc-1#xx...Ack
Packet received: OK
Sending packet: $c#63...Ack

since the '-1' in "Hc-1" indicates 'all threads'.

But, it does neither of this, and does something like this:
<gdb-thread1> continue
Sending packet: $Hc1#xx...Ack
Packet received: OK
Sending packet: $c#63...Ack
Sending packet: $Hc0#xx...Ack
Sending packet: $c#63...Ack

But '0' in "Hc0" indicates 'any thread'; Should the stub take this as an indication to continue all the threads ?

The document does not clearly explain whether the initiative, to stop all the threads once a thread hits a break and to continue all the threads if a continue is given from a thread, is the responsibility of gdb or stub, and how. And an inspection of gdb's packets sent to stub throw no light either.

Can someone clarify ?


Thanks,
Suresh

-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com

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

[Pedro Alves]

> On Wednesday 10 June 2009 08:18:19, suresh ds wrote:
> Re: Behaviour of default all-stop mode -- Why no one has replied ?

Because we're all volunteers and busy people here.

On Wednesday 10 June 2009 08:18:19, suresh ds wrote:
> I'm re-posting my previous query. 

Replying to the other query would be better, in terms
of preserving answers close to the questions, so that
other people googling around with the same problem have
better chances of finding them.

> The foll. are w.r.to remote debugging in gdb 6.8 cross-compiled for mips64.
> 
> In the default all-stop mode,

Non-stop mode was only added post 6.8, so, this is about how GDB
has behaved since ever.

> 
> 1) The document says, "whenever your program stops under GDB for any reason,all threads of execution stop, not just the current thread"
> -- Here, the initiation is done by gdb or the (remote) stub should take care of this ?

The stub.

> 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.

> 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.

> The document does not clearly explain whether the initiative, to stop all the threads once a thread hits a break and to continue all the threads if a continue is given from a thread, is the responsibility of gdb or stub, and how. And an inspection of gdb's packets sent to stub throw no light either.

I suggest studying the trafic between gdb and gdbserver.


I did find this in "D.10 Remote Protocol Support for Non-Stop Mode":

 "(...) In contrast to all-stop mode, where all threads in all processes
  are stopped when a stop reply is sent, in non-stop mode only the thread reporting the
  stop event is stopped.  (...)",

you can infer the all-stop behaviour from this, but, I agree with you that
it would be nice to clarify these points closer to the packet descriptions.

-- 
Pedro Alves