On Saturday 28 Feb 2004 6:38 am, George Anzinger wrote:
> Pavel Machek wrote:
> > Hi!
> >
> >>>+config KGDB_THREAD
> >>>+ bool "KGDB: Thread analysis"
> >>>+ depends on KGDB
> >>>+ help
> >>>+ With thread analysis enabled, gdb can talk to kgdb stub to list
> >>>+ threads and to get stack trace for a thread. This option also
> >>>enables
> >>>+ some code which helps gdb get exact status of thread. Thread
> >>>analysis
> >>>+ adds some overhead to schedule and down functions. You can disable
> >>>+ this option if you do not want to compromise on speed.
> >>
> >>Lets remove the overhead and eliminate the need for this option in favor
> >> of always having threads. Works in the mm kgdb...
> >
> > No. Thread analysis is unsuitable for the mainline (manipulates
> > sched.c in ugly way). It may be okay for -mm, but in such case it
> > should better be separated.
>
> Not in the -mm version. I agree that sched.c should NEVER be treated this
> way and it is not in the -mm version. I also think that, most of the time,
> it is useful to have the thread stuff, but that may be just my usage...
If threads stuff didn't introduce any unclean code changes, I too would prefer
to have it on all the time. As things stands, threads stuff is rather
intrusive.
-Amit
Amit S. Kale wrote:
> On Saturday 28 Feb 2004 6:38 am, George Anzinger wrote:
>
>>Pavel Machek wrote:
>>
>>>Hi!
>>>
>>>
>>>>>+config KGDB_THREAD
>>>>>+ bool "KGDB: Thread analysis"
>>>>>+ depends on KGDB
>>>>>+ help
>>>>>+ With thread analysis enabled, gdb can talk to kgdb stub to list
>>>>>+ threads and to get stack trace for a thread. This option also
>>>>>enables
>>>>>+ some code which helps gdb get exact status of thread. Thread
>>>>>analysis
>>>>>+ adds some overhead to schedule and down functions. You can disable
>>>>>+ this option if you do not want to compromise on speed.
>>>>
>>>>Lets remove the overhead and eliminate the need for this option in favor
>>>>of always having threads. Works in the mm kgdb...
>>>
>>>No. Thread analysis is unsuitable for the mainline (manipulates
>>>sched.c in ugly way). It may be okay for -mm, but in such case it
>>>should better be separated.
>>
>>Not in the -mm version. I agree that sched.c should NEVER be treated this
>>way and it is not in the -mm version. I also think that, most of the time,
>>it is useful to have the thread stuff, but that may be just my usage...
>
>
> If threads stuff didn't introduce any unclean code changes, I too would prefer
> to have it on all the time. As things stands, threads stuff is rather
> intrusive.
Lets put the threads stuff in the stub. The only stuff we need in the kernel is
the flag that indicateds that the pid hash table has been initialized.
Meanwhile, I would like to make a change to the gdb "info thread" command to do
a better job of displaying the threads. Here is what I am proposing:
Gdb would work as it does now if the following set is not done.
A new "set thread_level" command that would take the "bt" level to use on the
thread display.
A new "set thread_limits command that would take two expressions that would
reduce to two memory addresses.
Which ever of these is entered last will be active and used by "info thread" as
follows:
if thread_level is active gdb will do the indicated number of "up" operations
and display the result on the info thread line for that thread (note there is
other info on this line that will not be changed).
if thread_limits is active gdb will do 0 or more "up" commands until the
resultant PC is NOT between the given limits.
The kernel, at this time, has defined symbols for the thread_limits command (it
is used in the kernel for its internal display of threads). I would expect that
the thread_level version would be the answer for theaded application programs.
Daniel, how does this sound?
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
On Wednesday 03 Mar 2004 3:08 am, George Anzinger wrote:
> Amit S. Kale wrote:
> > On Saturday 28 Feb 2004 6:38 am, George Anzinger wrote:
> >>Pavel Machek wrote:
> >>>Hi!
> >>>
> >>>>>+config KGDB_THREAD
> >>>>>+ bool "KGDB: Thread analysis"
> >>>>>+ depends on KGDB
> >>>>>+ help
> >>>>>+ With thread analysis enabled, gdb can talk to kgdb stub to list
> >>>>>+ threads and to get stack trace for a thread. This option also
> >>>>>enables
> >>>>>+ some code which helps gdb get exact status of thread. Thread
> >>>>>analysis
> >>>>>+ adds some overhead to schedule and down functions. You can disable
> >>>>>+ this option if you do not want to compromise on speed.
> >>>>
> >>>>Lets remove the overhead and eliminate the need for this option in
> >>>> favor of always having threads. Works in the mm kgdb...
> >>>
> >>>No. Thread analysis is unsuitable for the mainline (manipulates
> >>>sched.c in ugly way). It may be okay for -mm, but in such case it
> >>>should better be separated.
> >>
> >>Not in the -mm version. I agree that sched.c should NEVER be treated
> >> this way and it is not in the -mm version. I also think that, most of
> >> the time, it is useful to have the thread stuff, but that may be just my
> >> usage...
> >
> > If threads stuff didn't introduce any unclean code changes, I too would
> > prefer to have it on all the time. As things stands, threads stuff is
> > rather intrusive.
>
> Lets put the threads stuff in the stub. The only stuff we need in the
> kernel is the flag that indicateds that the pid hash table has been
> initialized.
>
> Meanwhile, I would like to make a change to the gdb "info thread" command
> to do a better job of displaying the threads. Here is what I am proposing:
>
> Gdb would work as it does now if the following set is not done.
>
> A new "set thread_level" command that would take the "bt" level to use on
> the thread display.
> A new "set thread_limits command that would take two expressions that would
> reduce to two memory addresses.
>
> Which ever of these is entered last will be active and used by "info
> thread" as follows:
>
> if thread_level is active gdb will do the indicated number of "up"
> operations and display the result on the info thread line for that thread
> (note there is other info on this line that will not be changed).
You can already do a backtrace on all threads using gdb command
"thread apply all backtrace".
>
> if thread_limits is active gdb will do 0 or more "up" commands until the
> resultant PC is NOT between the given limits.
How does a user specify PC? There are umpteen number of kernel entry points
(irqs, exceptions, system calls).
> The kernel, at this time, has defined symbols for the thread_limits command
> (it is used in the kernel for its internal display of threads). I would
> expect that the thread_level version would be the answer for theaded
> application programs.
>
> Daniel, how does this sound?
The problem with kernel backtraces not stopping at kernel entry points is a
tough one. gdbmod at kgdb.sourceforge.net attempts to do that. This gdb
detects if we are debugging a kernel. If we are, a few things kick in like
scanning of modules instead of .so libraries and stopping backtraces earlier.
GDB uses main as the function where backtraces stop unless overridden. This is
broken by definition for multithreaded programs becauses non initial threads
don't start from main. Kernel too doesn't have main and has several entry
points.
If there is a way for gdb to know entry points from the kernel, it would be
very easy to maintain. Say a .entrypoint section that lists pc ranges of
entry points. GDB then stop a backtrace as soon as it enters one of these
ranges.
--
Amit Kale
EmSysSoft (http://www.emsyssoft.com)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)
Amit S. Kale wrote:
> On Wednesday 03 Mar 2004 3:08 am, George Anzinger wrote:
>
>>Amit S. Kale wrote:
>>
>>>On Saturday 28 Feb 2004 6:38 am, George Anzinger wrote:
>>>
>>>>Pavel Machek wrote:
>>>>
>>>>>Hi!
>>>>>
>>>>>
>>>>>>>+config KGDB_THREAD
>>>>>>>+ bool "KGDB: Thread analysis"
>>>>>>>+ depends on KGDB
>>>>>>>+ help
>>>>>>>+ With thread analysis enabled, gdb can talk to kgdb stub to list
>>>>>>>+ threads and to get stack trace for a thread. This option also
>>>>>>>enables
>>>>>>>+ some code which helps gdb get exact status of thread. Thread
>>>>>>>analysis
>>>>>>>+ adds some overhead to schedule and down functions. You can disable
>>>>>>>+ this option if you do not want to compromise on speed.
>>>>>>
>>>>>>Lets remove the overhead and eliminate the need for this option in
>>>>>>favor of always having threads. Works in the mm kgdb...
>>>>>
>>>>>No. Thread analysis is unsuitable for the mainline (manipulates
>>>>>sched.c in ugly way). It may be okay for -mm, but in such case it
>>>>>should better be separated.
>>>>
>>>>Not in the -mm version. I agree that sched.c should NEVER be treated
>>>>this way and it is not in the -mm version. I also think that, most of
>>>>the time, it is useful to have the thread stuff, but that may be just my
>>>>usage...
>>>
>>>If threads stuff didn't introduce any unclean code changes, I too would
>>>prefer to have it on all the time. As things stands, threads stuff is
>>>rather intrusive.
>>
>>Lets put the threads stuff in the stub. The only stuff we need in the
>>kernel is the flag that indicateds that the pid hash table has been
>>initialized.
>>
>>Meanwhile, I would like to make a change to the gdb "info thread" command
>>to do a better job of displaying the threads. Here is what I am proposing:
>>
>>Gdb would work as it does now if the following set is not done.
>>
>>A new "set thread_level" command that would take the "bt" level to use on
>>the thread display.
>>A new "set thread_limits command that would take two expressions that would
>>reduce to two memory addresses.
>>
>>Which ever of these is entered last will be active and used by "info
>>thread" as follows:
>>
>>if thread_level is active gdb will do the indicated number of "up"
>>operations and display the result on the info thread line for that thread
>>(note there is other info on this line that will not be changed).
>
>
> You can already do a backtrace on all threads using gdb command
> "thread apply all backtrace".
>
>
>>if thread_limits is active gdb will do 0 or more "up" commands until the
>>resultant PC is NOT between the given limits.
>
>
> How does a user specify PC? There are umpteen number of kernel entry points
> (irqs, exceptions, system calls).
We are not interested in that. There are two entry points in the kernel:
void scheduling_functions_start_here(void);
void scheduling_functions_end_here(void);
that bound the area we don't want to show the task in in the info thread
command. $PC is the same as $ESP in the x86, but it is defined in all archs
regardless of the particular local name for the stack pointer.
>
>
>>The kernel, at this time, has defined symbols for the thread_limits command
>>(it is used in the kernel for its internal display of threads). I would
>>expect that the thread_level version would be the answer for theaded
>>application programs.
>>
>>Daniel, how does this sound?
>
>
>
> The problem with kernel backtraces not stopping at kernel entry points is a
> tough one. gdbmod at kgdb.sourceforge.net attempts to do that. This gdb
> detects if we are debugging a kernel. If we are, a few things kick in like
> scanning of modules instead of .so libraries and stopping backtraces earlier.
Stopping "bt" is a different problem, one which should be addressed by fixing up
the debug frame records to indicate where the bottom of the stack is. I have
code for this for the x86, but it uses CPP macros rather than the gas interface
for such which is rather restrictive.
>
> GDB uses main as the function where backtraces stop unless overridden. This is
> broken by definition for multithreaded programs becauses non initial threads
> don't start from main. Kernel too doesn't have main and has several entry
> points.
>
> If there is a way for gdb to know entry points from the kernel, it would be
> very easy to maintain. Say a .entrypoint section that lists pc ranges of
> entry points. GDB then stop a backtrace as soon as it enters one of these
> ranges.
No, this is not enough. It needs to also know to stop when the interrupt/ trap
returns to user space. You might try the attached patch. Be warned, however,
that it requires a CVS gdb (I found broken code).
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml