This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]