From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27687 invoked by alias); 15 Jun 2009 15:10:04 -0000 Received: (qmail 27602 invoked by uid 22791); 15 Jun 2009 15:10:00 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_63 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, 15 Jun 2009 15:09:47 +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 B76547A0D28 for ; Mon, 15 Jun 2009 15:09:45 +0000 (GMT) X-OB-Received: from unknown (208.36.123.73) by wfilter3.us4.outblaze.com; 15 Jun 2009 15:09:45 -0000 Received: by ws1-9.us4.outblaze.com (Postfix, from userid 1001) id 0332EBE407F; Mon, 15 Jun 2009 15:09:45 +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, 15 Jun 2009 15:10: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, 15 Jun 2009 10:09:44 -0500 X-Ob-Auth: dssuresh66:mail.com@mail.com Message-Id: <20090615150945.0332EBE407F@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-06/txt/msg00144.txt.bz2 Thanks for the reply. I think I've to explain a bit more here to indicate what problems I face an= d 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 compile= d along with the stub (which means each of these n*m threads will run an im= age which consists of application + stub). The stub is a kind of library wh= ich the images link to while getting compiled. I don't have the luxury of k= eeping 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 conn= ects, 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 so= ftware 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 a= ware...). As gdb connects to the default hardware thread 1 (shortly, ht1), the stub s= itting in ht1 responds to queries (including the '?' packet). At this stage= , note that all hardware threads are stopped. When gdb queries with a '?' t= o 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 th= e hardware threads or not, didn't solve the problem. Initially, I tried onl= y "$T05:thread:1", which means only that default thread sent its status. Th= en 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 gd= b 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 i= f 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 s= tep or continue other threads. Even an "info reg" is not guaranteed to fetc= h 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 =3D= =3D>> (gdb)target remote 10.7.8.68:5000 Remote debugging using 10.7.8.68:5000 Sending packet: $qSupported#37...Ack Packet received:=20 Packet qSupported (supported-packets) is NOT supported Sending packet: $g#67...Ack Packet received: 00000000000000000000000050000001ffffffff800b4000ffffffff80= 0b40200000000000000001000000000080000000000000018066a8000000000000000100000= 0000180683800000000018067280000000000000001ffffffff800b00000000000000000001= 000000000087170c00000000000000600000000000000070000000000000001000000000008= 7172cffffffff900ddeed0000000000000004000000000080000000000000002d0000000000= 00009538780000000000800000ffffffff800b4000ffffffff800b404000000000000000000= 000000000000000000000000080ac5000000000008f2e800000000000000001000000000023= b2fc0000000050000003000000000121eac00000000000f4240000000000008000000000000= 000008024000000000023741000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000 Sending packet: $?#3f...Ack Packet received: T05thread:4;thread:5;thread:6; =3D=3D>> Well, the stub sitting on thread 4 (default hardware thread) corre= sponds to gdb here. It also sends the status of other (hardware) threads. I= nitially, I made thread 4 pass only its status as "$T05thread:4", but no di= fference. Sending packet: $Hc-1#09...Ack =3D=3D>> 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=3D0;Data=3D0;Bss=3D0 [New Thread 4] [New Thread 5] [New Thread 6] Sending packet: $g#67...Ack Packet received: 00000000000000000000000050000001ffffffff800b4000ffffffff80= 0b40200000000000000001000000000080000000000000018066a8000000000000000100000= 0000180683800000000018067280000000000000001ffffffff800b00000000000000000001= 000000000087170c00000000000000600000000000000070000000000000001000000000008= 7172cffffffff900ddeed0000000000000004000000000080000000000000002d0000000000= 00009538780000000000800000ffffffff800b4000ffffffff800b404000000000000000000= 000000000000000000000000080ac5000000000008f2e800000000000000001000000000023= b2fc0000000050000003000000000121eac00000000000f4240000000000008000000000000= 000008024000000000023741000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000 Sending packet: $g#67...Ack Packet received: 00000000000000000000000050000001ffffffff800b4000ffffffff80= 0b40200000000000000001000000000080000000000000018066a8000000000000000100000= 0000180683800000000018067280000000000000001ffffffff800b00000000000000000001= 000000000087170c00000000000000600000000000000070000000000000001000000000008= 7172cffffffff900ddeed0000000000000004000000000080000000000000002d0000000000= 00009538780000000000800000ffffffff800b4000ffffffff800b404000000000000000000= 000000000000000000000000080ac5000000000008f2e800000000000000001000000000023= b2fc0000000050000003000000000121eac00000000000f4240000000000008000000000000= 000008024000000000023741000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000 [Switching to Thread 6] =3D=3D>> 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=20=20=20=20=20 =20=20=20=20=20=20=20=20 Sending packet: $qSymbol::#5b...Ack Packet received:=20 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: 00000000000000000000000050000001ffffffff800b4000ffffffff80= 0b40200000000000000001000000000080000000000000018066a8000000000000000100000= 0000180683c00000000018067280000000000000001ffffffff800b00000000000000000001= 000000000087170d00000000000000000000000000000020000000000000002000000000008= 7172dffffffff900ddeed0000000000000005000000000080000000000000002d0000000000= 0000953a780000000000800000ffffffff800b4000ffffffff800b404000000000000000000= 000000000000000000000000080ac5000000000008f2e800000000000000001000000000023= b2fc0000000050000003000000000121eac00000000000f4240000000000008000000000000= 000008024000000000023741000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000 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: 00000000000000000000000050000001ffffffff800b4000ffffffff80= 0b40200000000000000001000000000080000000000000018066a8000000000000000100000= 0000180683800000000018067280000000000000001ffffffff800b00000000000000000001= 000000000087170c00000000000000600000000000000070000000000000001000000000008= 7172cffffffff900ddeed0000000000000004000000000080000000000000002d0000000000= 00009538780000000000800000ffffffff800b4000ffffffff800b404000000000000000000= 000000000000000000000000080ac5000000000008f2e800000000000000001000000000023= b2fc0000000050000003000000000121eac00000000000f4240000000000008000000000000= 000008024000000000023741000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000 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: 00000000000000000000000050000001ffffffff800b4000ffffffff80= 0b40200000000000000001000000000080000000000000018066a8000000000000000100000= 0000180684000000000018067280000000000000001ffffffff800b00000000000000000001= 000000000087170e00000000000000200000000000000060000000000000004000000000008= 7172effffffff900ddeed0000000000000006000000000080000000000000002d0000000000= 0000953c780000000000800000ffffffff800b4000ffffffff800b404000000000000000000= 000000000000000000000000080ac5000000000008f2e800000000000000001000000000023= b2fc0000000050000003000000000121eac00000000000f4240000000000008000000000000= 000008024000000000023741000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000 =3D=3D>> At this point, gdb is made aware that there are three threads wait= ing to be debugged; Already, the presence of these threads were also indica= ted 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 =3D=3D>> 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 he= re, it does not indicate. So, which thread should I resume ? Actually, I re= sumed the default thread (4). Should the stub resume all the threads even t= hough it has not received any thread no. ? Now, this is without any breakpoints set. Even if I set a breakpoint and co= ntinue, it only continues the 'current' thread. I typically expect somethin= g like this from gdb. "$vCont;c:4;c:5;blahblah". After thread 4 hits the br= eakpoint, 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 e= xpected behaviour in default all-stop mode ? In our earlier discussions, yo= u have mentioned that that stub itself should not resume all the threads an= d that the gdb will indicate that through vCont packets, which is not happe= ning here. Please help. 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, 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=20 > > gdb; At this point, gdb itself will send (further) packets to >=20 > stop other threads, or the stub itself should take the initiative=20 > > to stop other threads ? > > The stub. > > =3D=3D>> So, the stub take the initiative to stop other threads. In=20 > this case, the other threads' status should also be reported to=20 > 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 >=20 > threads start executing". > > -- Again, the gdb takes initiative to continue all the threads=20 > 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=20 > 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=20 > > set the further continue packets only for thread 1. > > Implement vCont support instead, s,c,Hc are deprecated for=20 > multithreaded stubs. > > =3D=3D>> But I get indication from gdb only to start one thread;=20 > Maybe, this will change if the stub reports the status of all the=20 > 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. > > =3D=3D>> I tried debugging a pthread program through gdbserver on=20 > intel-i386. But info threads was not recognizing the threads; I=20 > don't know if I should compile/configure gdbserver separately for=20 > 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 --=20 Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com