From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11894 invoked by alias); 30 Dec 2003 04:19:04 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 11887 invoked from network); 30 Dec 2003 04:19:04 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 30 Dec 2003 04:19:04 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AbBLP-0007aq-IK; Mon, 29 Dec 2003 23:18:59 -0500 Date: Tue, 30 Dec 2003 04:19:00 -0000 From: Daniel Jacobowitz To: "Amit S. Kale" Cc: George Anzinger , gdb@sources.redhat.com, kgdb-bugreport@lists.sourceforge.net Subject: Re: qL and qf remote packets [Re: [Kgdb-bugreport] Re: [discuss] kgdb-x86_64-1.6 for kernel 2.4.23] Message-ID: <20031230041859.GA29114@nevyn.them.org> Mail-Followup-To: "Amit S. Kale" , George Anzinger , gdb@sources.redhat.com, kgdb-bugreport@lists.sourceforge.net References: <200312261743.38980.amitkale@emsyssoft.com> <200312292009.11853.amitkale@emsyssoft.com> <3FF05F54.5050702@mvista.com> <200312300937.48484.amitkale@emsyssoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312300937.48484.amitkale@emsyssoft.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-12/txt/msg00279.txt.bz2 On Tue, Dec 30, 2003 at 09:37:47AM +0530, Amit S. Kale wrote: > GDB Gurus, > > Can we get some help on following problems we face with thread list scanning > in kgdb, please? > > 1. Kernel has multiple idle threads with pid 0. There is no easy way to > present this to gdb. The solution discussed below uses pids > PID_MAX to > represent them. Is there a better other way to do this? > > [ George, Thanks for this explanation. I have removed x86_64 mailing list from > To list as the x86_64 patch doesn't contain PID_MAX workaround.] GDB tracks the threads by their TID, at least in its current incarnation. So I think you'll have to come up with unique PIDs for these; and above PID_MAX seems like the best place to put them. > 2. Packet qL has a problem with pid wrapping around PID_MAX. This was because > gdb didn't scan for a pid once it knows that there is no thread with that > pid. George and I worked through this problem for a little while. The upshot was, as he said below, it seemed to vanish with the switch to qfThreadInfo. I never reproduced the problem, so we never got to the bottom of it. Use qfThreadInfo instead. > 3. q[sf]ThreadInfo packets have a problem with pids wrapping around PID_MAX. > gdb will know that a thread exists after it has died. What happens then? I'm afraid I don't understand what you mean. What's the problem? qfThreadInfo should not have whatever wrapping problems that qL did. It always queries for the whole list. > > Thanks. > > On Monday 29 Dec 2003 10:37 pm, George Anzinger wrote: > > Amit S. Kale wrote: > > > I am going to work on kgdb-x86_64 for 2.6 kernels also in a couple of > > > weeks. I am going to merge the kgdb from 2.6-mm patches and one from > > > kgdb.sourceforge.net first. > > > > > > The patches released by me indeed isn't as good as i386 kgdb, though I'll > > > try to fix problems I can understand. > > > > > > Andi, can you tell me me on why interrupt, exception threads were created > > > in the kgdb stub? I guess the reason for that is gdb doesn't show stack > > > frames beyond do_IRQ. > > > > Since I did the kgdb on Andrews site, let me try to answer this. I assume > > you are refering to the way the idle threads are handled. They are given > > PIDs PID_MAX+1 and up. The reason is that all idle thread in and smp box > > are set up as PID 0. This is a bit confusing so the above dodge was used. > > The result is that we now see all the idle threads an not just the first > > one. No threads are actually created. There may be an issue of not > > suppressing thread zero in the scan, however. I don't rememer if I fixed > > this yet or not. The result is that thread 0 may show up as both thread 0 > > and PID_MAX+1. No real harm done. > > > > > This stub and the kgdb from ftp.x86-64.org use 'qf' packet instead of > > > 'qL'. Was this changed because interrupt threads would create problems > > > with 'qL' packet? qL query scans thread in ascending order of thread id, > > > hence it would assume that threads between highest thread number and > > > 0x9001,0x9002 were absent and would never be created. > > > > As far as I can tell, qf is just a new way of doing the same thing AND is > > much more conservative in band width. qL is, I think, being phased out. > > However, the reason for the move was that qL is broken, either in gdb or > > the stub. I could not figure out which but since qf works, I did not look > > further. The symptom of breakage was that thread info requests after the > > first one would not find new threads but would only report what remainded > > of the ones first reported. Ah, I see, you point to the problem above. > > Thanks > > > > > 1.9 version of kgdb has architecture independent parts of i386 and > > > powerpc merged and moved into kernel directory. I'll have to do that for > > > x86_64. That implies removing interrupt and exception threads and > > > changing 'qf' to 'qL'. > > > > I think this is NOT the way to go. We do need to know about the idle > > threads. Often they are holding spinlocks (from interrupt routines) that > > block the system. Could you indicate why this is a problem for you? > > > > -g > > > > > On Monday 29 Dec 2003 1:10 am, Andi Kleen wrote: > > >>On Sat, 27 Dec 2003 11:23:36 +0100 > > >> > > >>Pavel Machek wrote: > > >>>Hi! > > >>> > > >>>>I have started maintaining kgdb for x86_64 architecture at > > >>>>http://kgdb.sourceforge.net/ > > >>>> > > >>>>Current kgdb-x86_64 version is 1.6. It features console messages > > >>>>through gdb. > > >>> > > >>>That's kgdb for 2.4.X or kgdb for 2.6.X? [I'll need to get kgdb > > >>>working on 2.6.X real soon...] > > >> > > >>It's basically my old stub for 2.4 from ftp.x86-64.org/pub/linux/debug/* > > >>with the attributions dropped or something. It has many problems, but > > >>I guess it is better than nothing. > > >> > > >>There is a port of the much enhanced 2.6 stub from -mm* in the pipeline, > > >>but not completely finished yet (from Jim Houston). That one should be > > >> much better. > > >> > > >>There is also a 2.4 port of kdb now (contributed by someone else), > > >>but I first need to clean it up a bit before I can release it on the ftp > > >>site. > > >> > > >>-Andi > > -- > Amit Kale > EmSysSoft (http://www.emsyssoft.com) > KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net) > > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer