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

Pedro Alves
2009-07-06T17:03:51Z

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