qL and qf remote packets [Re: [Kgdb-bugreport] Re: [discuss] kgdb-x86_64-1.6 for kernel 2.4.23]

["Amit S. Kale" <amitkale at emsyssoft dot com>]

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.]

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.

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?

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)