This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


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