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

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

[Amit S. Kale]

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)

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

[Daniel Jacobowitz]

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

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

[Amit S. Kale]

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)

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

[Daniel Jacobowitz]

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

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

[Andrew Cagney]

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

The user might (eventually).  They aren't going to be notified of thread 
create/delete events.  Also, it could leave around per-thread 
breakpoings no longer applicable to that thread.

However, until someone manages to present this as a real problem ...

Andrew

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

[George Anzinger]

Andrew Cagney wrote:
>> 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.
> 
> 
> The user might (eventually).  They aren't going to be notified of thread 
> create/delete events.  Also, it could leave around per-thread 
> breakpoings no longer applicable to that thread.

I think this might be more of a problem in user land.  In the kernel, first it 
is rare to reuse a pid, but still, if it is reused, it is expected.  To help the 
user we also use the thread info command to insert the tasks name in the info 
thread command.


-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

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

[Andrew Cagney]

>> The user might (eventually).  They aren't going to be notified of thread create/delete events.  Also, it could leave around per-thread breakpoings no longer applicable to that thread.
> 
> I think this might be more of a problem in user land.  In the kernel, first it is rare to reuse a pid, but still, if it is reused, it is expected.  To help the user we also use the thread info command to insert the tasks name in the info thread command. 

Ok, I'll wait for someone to notice a real problem  .... :-)

Andrew

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

[Daniel Jacobowitz]

On Wed, Dec 31, 2003 at 02:25:42PM -0500, Andrew Cagney wrote:
> >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.
> 
> The user might (eventually).  They aren't going to be notified of thread 
> create/delete events.  Also, it could leave around per-thread 
> breakpoings no longer applicable to that thread.
> 
> However, until someone manages to present this as a real problem ...

I suggested a protocol for describing the create/delete events, but it
was dropped because it was "too asynchronous" IIRC?  Certainly with
kgdb stopping the system to report thread create/delete events isn't
acceptable, so I don't know quite what to do about that.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer