From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8741 invoked by alias); 6 Jul 2009 17:03:51 -0000 Received: (qmail 8183 invoked by uid 22791); 6 Jul 2009 17:03:48 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 06 Jul 2009 17:03:35 +0000 Received: (qmail 17911 invoked from network); 6 Jul 2009 17:03:33 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Jul 2009 17:03:33 -0000 From: Pedro Alves To: "suresh ds" Subject: Re: Behaviour of default all-stop mode -- Why no one has replied ? Date: Mon, 06 Jul 2009 17:03:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb@sourceware.org References: <20090706142104.E3D55326701@ws1-8.us4.outblaze.com> In-Reply-To: <20090706142104.E3D55326701@ws1-8.us4.outblaze.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907061804.19968.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-07/txt/msg00034.txt.bz2 On Monday 06 July 2009 15:21:04, suresh ds wrote: > After some trial and error, I observed that "vCont;c" indicates that 'c'o= ntinue should be applied to all the threads that do not have any default ac= tion specified. Actually, gdb documentation could have been clearer; I read= it a few times, tried out a few times, only then understood the vCont beha= viour. 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: >=20 > 1) Does gdb support threads with shared text ?=20 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 optio= n has to be turned on (in gdb)?=20 No. >=20 > 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 bel= ow: >=20 > (gdb)target remote : > Remote debugging using : > Sending packet: $qSupported#37...Ack > Packet received:=20 > Packet qSupported (supported-packets) is NOT supported > Sending packet: $g#67...Ack > Packet received: 0000000000000000000000005000000100000000000000a000000000= 000000100000000000000001000000000087000000000000000000b0ffffffff900ddeed000= 00000018066ac00000000018066f8ffffffff800b4000000000000180686800000000018067= 680000000000000001000000000087170400000000008717240000000001806878000000000= 0800000ffffffff800b40400000000000000004000000000080000000000000002d00000000= 0000009538780000000000800000ffffffff800b40000000000000000001000000000000000= 00000000000000000000000000080ac5000000000008f2e8000000000000000010000000000= 23a9fc000000005000000300000000015be680000000000124f800000000000080000000000= 000000080240000000000237578000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 00000000000000000000000000000000000000000000000000000000000000 > 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=3D0;Data=3D0;Bss=3D0 > [New Thread 4] > Sending packet: $g#67...Ack > Packet received: 0000000000000000000000005000000100000000000000a000000000= 000000100000000000000001000000000087000000000000000000b0ffffffff900ddeed000= 00000018066ac00000000018066f8ffffffff800b4000000000000180686800000000018067= 680000000000000001000000000087170400000000008717240000000001806878000000000= 0800000ffffffff800b40400000000000000004000000000080000000000000002d00000000= 0000009538780000000000800000ffffffff800b40000000000000000001000000000000000= 00000000000000000000000000080ac5000000000008f2e8000000000000000010000000000= 23a9fc000000005000000300000000015be680000000000124f800000000000080000000000= 000000080240000000000237578000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 00000000000000000000000000000000000000000000000000000000000000 > 0x00237578 in gdb_break () > at blah..blah.. > 85 blah..blah.. > in blah..blah.. > Sending packet: $qSymbol::#5b...Ack > Packet received:=20 > 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: 000000000000000000000000500000010000000000802c54ffffffff= ffffffff000000000000000000000000008f2fe000000000008f2fe80000000000000000000= 00000008000000000000000000001ffffffff800b4000000000000180686800000000018067= 680000000000000001000000000087170700000000008717270000000000000620ffffffff8= c2626880000000000980000ffffffff8c145b88ffffffff8c26268800000000000000010000= 00000098968000000000000030c8ffffffff800b40000000000000000000000000000000000= 00000000000000000000000000080ac5000000000008f2f3800000000000000000000000000= 200720000000005000000300000000015be680000000000124f80000810d688c26ce1000000= 000000080240000000000200388000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 00000000000000000000000000000000000000000000000000000000000000 > Sending packet: $g#67...Ack > Packet received: 000000000000000000000000500000010000000000802c54ffffffff= ffffffff000000000000000000000000008f2fe000000000008f2fe80000000000000000000= 00000008000000000000000000001ffffffff800b4000000000000180686800000000018067= 680000000000000001000000000087170700000000008717270000000000000620ffffffff8= c2626880000000000980000ffffffff8c145b88ffffffff8c26268800000000000000010000= 00000098968000000000000030c8ffffffff800b40000000000000000000000000000000000= 00000000000000000000000000080ac5000000000008f2f3800000000000000000000000000= 200720000000005000000300000000015be680000000000124f80000810d688c26ce1000000= 000000080240000000000200388000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 00000000000000000000000000000000000000000000000000000000000000 > [Switching to Thread 7] > Sending packet: $z0,200388,4#6b...Ack > Packet received: OK >=20 > 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: 000000000000000000000000500000010000000000000002ffffffff= ffffffff000000000000000000000000008f2fe000000000008f2fe80000000000000000000= 00000008000000000000000000001ffffffff800b4000000000000180686800000000018067= 680000000000000001000000000087170700000000008717270000000000000620ffffffff8= c2626880000000000980000ffffffff8c145b88ffffffff8c26268800000000000000010000= 00000098968000000000000030c8ffffffff800b40000000000000000000000000000000000= 00000000000000000000000000080ac5000000000008f2f3800000000000000000000000000= 200720000000005000000300000000015be680000000000124f80000810d688c26ce1000000= 00000008024000000000020038c000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 00000000000000000000000000000000000000000000000000000000000000 > 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: 00000000000000000000000050000000000000005000000100000000= 0000000b000000000000000b0000000000800398000000000000000a0000000000000001000= 00000008000000000000000000001ffffffffbef1400000000000008f26b400000000008e07= 600000000000800000ffffffffffffffff00000000000000010000000000800000ffffffff8= c2626880000000000980000ffffffff8c145b88ffffffff8c26268800000000000000010000= 00000098968000000000000030c8000000000000000700000000000000010000000b0000000= 0002cedf000000000000000000080ac5000000000008f2f3800000000000000000000000000= 200720000000005000000300000000015be680000000000124f800ffffffff8c145b8800000= 000000080240000000000200388000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 00000000000000000000000000000000000000000000000000000000000000 > Sending packet: $z0,200388,4#6b...Ack > Packet received: OK >=20 > 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 >=20 > <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> >=20 > 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 acknow= ledges this by typing "[Switching to Thread 7]". A further continue gives r= ise to the foll. sequence (and my comments are intersperced): >=20 > (rmios-gdb)c > Continuing. > Sending packet: $vCont;s:7#29...Ack > Packet received: T05thread:7; >=20 > <=3D=3D> At this point, gdb makes Thread 7 to step while indicating nothi= ng for the other threads >=20 > Sending packet: $g#67...Ack > Packet received: blah...blah.. > Sending packet: $Z0,200388,4#4b...Ack > Packet received: OK >=20 > <=3D=3D> Once Thread 7 single steps, it inserts the breakpoint; Note that= other threads have not yet moved, but the breakpoint is already inserted b= ack !! >=20 > Sending packet: $vCont;c#a8...Ack > Packet received: T05thread:7; >=20 > <=3D=3D> Now, gdb makes all threads to continue. But this only makes Thre= ad 7 to continue and other threads are still at the same point, because the= y came out of exception, and tried to execute the same PC which has the add= ress with breakpoint already inserted back, so they hit the break again wit= hout really proceeding.=20 So now would be a good time to report one of those threads has having hit t= he breakpoint. Remember that events are serialized to GDB. > Since Thread 7 has already single-stepped, it does not see this break (wh= ich it itself inserted), proceeds further, later hits this break again (as = the code is in a loop).=20 This depends on your stub and OS scheduler. If another thread had hit the = same breakpoint, then by all means, report that instead. >=20 > 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; >=20 > This will ensure that all threads have single-stepped once, then the brea= k 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. >=20 > 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 j= ust keep hitting the break again and again. Have the stub report that to GDB. Eventually the user types enough "contin= ue"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 s= pecific breakpoint" instead. "break foofunc thread 4", for example. > Note that the above problem occurs because the threads share the code (te= xt). If they indeed are running different texts, then this problem would no= t 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. --=20 Pedro Alves