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]


While q[s/f] packet itself doesn't have pid wrap-around problem, I can't 
figure out what will happen to gdb's database of threads in following 
scenario.

1. GDB adds a thread with id 1500 to thread database.
2. It finds that the thread has died later.
3. Does it delete the thread from its database?
4. It again finds a thread with id 1500 becase of wrapping around of pid. If 
it has completely forgotten about previous thread in its dabase, there 
shouldn't be any problem.

On Tuesday 30 Dec 2003 9:48 am, Daniel Jacobowitz wrote:
> 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)

-- 
Amit Kale
EmSysSoft (http://www.emsyssoft.com)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)


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