From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18704 invoked by alias); 20 Jul 2009 10:50:35 -0000 Received: (qmail 18690 invoked by uid 22791); 20 Jul 2009 10:50:34 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from outbound1-1.us4.outblaze.com (HELO outbound1-1.us4.outblaze.com) (208.36.123.129) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Jul 2009 10:50:26 +0000 Received: from wfilter3.us4.outblaze.com.int (wfilter3.us4.outblaze.com.int [192.168.8.242]) by outbound1-1.us4.outblaze.com (Postfix) with QMQP id BF79B7A1615 for ; Mon, 20 Jul 2009 10:50:23 +0000 (GMT) X-OB-Received: from unknown (208.36.123.73) by wfilter3.us4.outblaze.com; 20 Jul 2009 10:50:23 -0000 Received: by ws1-9.us4.outblaze.com (Postfix, from userid 1001) id A9543BE407F; Mon, 20 Jul 2009 10:50:23 +0000 (GMT) Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 From: "suresh ds" To: "Pedro Alves" Cc: gdb@sourceware.org Date: Mon, 20 Jul 2009 10:50:00 -0000 Subject: Re: Behaviour of default all-stop mode -- Why no one has replied ? Received: from [203.92.57.132] by ws1-9.us4.outblaze.com with http for dssuresh66@mail.com; Mon, 20 Jul 2009 05:50:23 -0500 X-Ob-Auth: dssuresh66:mail.com@mail.com Message-Id: <20090720105023.A9543BE407F@ws1-9.us4.outblaze.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/msg00134.txt.bz2 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=20 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 t= o gdb. What this all means is, gdb may get the single step status after quite some time and not immed= iately after one does "step". Is this OK ? (ii) There is also another possibility. Some other thread may hit this sing= le step breakpoint, remove the breakpoint and report it than the actual thr= ead 1, which is supposed=20 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 t= his single step breakpoint itself, they do not report it and wait for threa= d 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"=20 To: "suresh ds"=20 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=20 > that 'c'ontinue should be applied to all the threads that do not=20 > have any default action specified. Actually, gdb documentation=20 > could have been clearer; I read it a few times, tried out a few=20 > times, only then understood the vCont behaviour. I saw your mail=20 > later with your explanation of vCont which confirms my=20 > understanding is correct. Well, anyway, vCont is implemented and=20 > 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=20 > in which case the function becomes shared code for those threads.=20 > Any specific option has to be turned on (in gdb)? No. > > 2) I've mapped gdb threads to hardware threads in a=20 > multi-processor MIPS SoC and these hardware threads share the=20 > text. Theoritically, this is same as a function shared by=20 > 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:=20 > 0000000000000000000000005000000100000000000000a00000000000000010000000000= 0000001000000000087000000000000000000b0ffffffff900ddeed00000000018066ac0000= 0000018066f8ffffffff800b400000000000018068680000000001806768000000000000000= 10000000000871704000000000087172400000000018068780000000000800000ffffffff80= 0b40400000000000000004000000000080000000000000002d0000000000000095387800000= 00000800000ffffffff800b4000000000000000000100000000000000000000000000000000= 000000000080ac5000000000008f2e800000000000000001000000000023a9fc00000000500= 0000300000000015be680000000000124f80000000000008000000000000000008024000000= 000023757800000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000 > 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:=20 > 0000000000000000000000005000000100000000000000a00000000000000010000000000= 0000001000000000087000000000000000000b0ffffffff900ddeed00000000018066ac0000= 0000018066f8ffffffff800b400000000000018068680000000001806768000000000000000= 10000000000871704000000000087172400000000018068780000000000800000ffffffff80= 0b40400000000000000004000000000080000000000000002d0000000000000095387800000= 00000800000ffffffff800b4000000000000000000100000000000000000000000000000000= 000000000080ac5000000000008f2e800000000000000001000000000023a9fc00000000500= 0000300000000015be680000000000124f80000000000008000000000000000008024000000= 000023757800000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000 > 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:=20 > 000000000000000000000000500000010000000000802c54ffffffffffffffff000000000= 000000000000000008f2fe000000000008f2fe8000000000000000000000000008000000000= 000000000001ffffffff800b400000000000018068680000000001806768000000000000000= 1000000000087170700000000008717270000000000000620ffffffff8c2626880000000000= 980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000= 000000030c8ffffffff800b4000000000000000000000000000000000000000000000000000= 000000000080ac5000000000008f2f380000000000000000000000000020072000000000500= 0000300000000015be680000000000124f80000810d688c26ce100000000000008024000000= 000020038800000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000 > Sending packet: $g#67...Ack > Packet received:=20 > 000000000000000000000000500000010000000000802c54ffffffffffffffff000000000= 000000000000000008f2fe000000000008f2fe8000000000000000000000000008000000000= 000000000001ffffffff800b400000000000018068680000000001806768000000000000000= 1000000000087170700000000008717270000000000000620ffffffff8c2626880000000000= 980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000= 000000030c8ffffffff800b4000000000000000000000000000000000000000000000000000= 000000000080ac5000000000008f2f380000000000000000000000000020072000000000500= 0000300000000015be680000000000124f80000810d688c26ce100000000000008024000000= 000020038800000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000 > [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:=20 > 000000000000000000000000500000010000000000000002ffffffffffffffff000000000= 000000000000000008f2fe000000000008f2fe8000000000000000000000000008000000000= 000000000001ffffffff800b400000000000018068680000000001806768000000000000000= 1000000000087170700000000008717270000000000000620ffffffff8c2626880000000000= 980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000= 000000030c8ffffffff800b4000000000000000000000000000000000000000000000000000= 000000000080ac5000000000008f2f380000000000000000000000000020072000000000500= 0000300000000015be680000000000124f80000810d688c26ce100000000000008024000000= 000020038c00000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000 > 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:=20 > 000000000000000000000000500000000000000050000001000000000000000b000000000= 000000b0000000000800398000000000000000a000000000000000100000000008000000000= 000000000001ffffffffbef1400000000000008f26b400000000008e0760000000000080000= 0ffffffffffffffff00000000000000010000000000800000ffffffff8c2626880000000000= 980000ffffffff8c145b88ffffffff8c2626880000000000000001000000000098968000000= 000000030c8000000000000000700000000000000010000000b00000000002cedf000000000= 000000000080ac5000000000008f2f380000000000000000000000000020072000000000500= 0000300000000015be680000000000124f800ffffffff8c145b880000000000008024000000= 000020038800000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000 > 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 > > <=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> > > I want to point out a few things. Here, four threads are running,=20 > 4,5,6,7. Thread 7 hits the breakpoint and stops other threads=20 > too; gdb also acknowledges this by typing "[Switching to Thread=20 > 7]". A further continue gives rise to the foll. sequence (and my=20 > comments are intersperced): > > (rmios-gdb)c > Continuing. > Sending packet: $vCont;s:7#29...Ack > Packet received: T05thread:7; > > <=3D=3D> At this point, gdb makes Thread 7 to step while indicating=20 > nothing for the other threads > > Sending packet: $g#67...Ack > Packet received: blah...blah.. > Sending packet: $Z0,200388,4#4b...Ack > Packet received: OK > > <=3D=3D> Once Thread 7 single steps, it inserts the breakpoint; Note=20 > that other threads have not yet moved, but the breakpoint is=20 > already inserted back !! > > Sending packet: $vCont;c#a8...Ack > Packet received: T05thread:7; > > <=3D=3D> Now, gdb makes all threads to continue. But this only makes=20 > Thread 7 to continue and other threads are still at the same=20 > point, because they came out of exception, and tried to execute=20 > the same PC which has the address with breakpoint already=20 > inserted back, so they hit the break again without really=20 > proceeding. So now would be a good time to report one of those threads has=20 having hit the breakpoint. Remember that events are serialized to=20 GDB. > Since Thread 7 has already single-stepped, it does not see this=20 > break (which it itself inserted), proceeds further, later hits=20 > this break again (as the code is in a loop). This depends on your stub and OS scheduler. If another thread had=20 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=20 > the break can be inserted and the threads can be proceeded. Not. Remember that events are serialized to GDB. From GDB's and=20 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=20 > 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=20 > all and just keep hitting the break again and again. Have the stub report that to GDB. Eventually the user types enough=20 "continue"s to move all threads passed the breakpoint. If the user is only=20 interested in being reported of a breakpoint hits in a specific thread, she can set a=20 "thread specific breakpoint" instead. "break foofunc thread 4", for example. > Note that the above problem occurs because the threads share the=20 > code (text). If they indeed are running different texts, then=20 > this problem would not arise at all, which makes me think, does=20 > 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 --=20 Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com