This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: qL and qf remote packets [Re: [Kgdb-bugreport] Re: [discuss] kgdb-x86_64-1.6 for kernel 2.4.23]
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: "Amit S. Kale" <amitkale at emsyssoft dot com>
- Cc: George Anzinger <george at mvista dot com>, gdb at sources dot redhat dot com,kgdb-bugreport at lists dot sourceforge dot net
- Date: Mon, 29 Dec 2003 23:18:59 -0500
- Subject: Re: qL and qf remote packets [Re: [Kgdb-bugreport] Re: [discuss] kgdb-x86_64-1.6 for kernel 2.4.23]
- References: <200312261743.38980.amitkale@emsyssoft.com> <200312292009.11853.amitkale@emsyssoft.com> <3FF05F54.5050702@mvista.com> <200312300937.48484.amitkale@emsyssoft.com>
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 <pavel@suse.cz> 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