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 06:11:29PM +0530, Amit S. Kale wrote:
> 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.

Indeed, there won't be any problem.  I believe that even if thread 1500
exists, and then dies and restarts between breakpoints, GDB still won't
get confused.

> 
> 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)
> 
> 

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