Re: [Kgdb-bugreport] [KGDB PATCH][1/7] Add / use kernel/Kconfig.kgdb

George Anzinger
2004-03-04T00:18:41Z

[-- Attachment #1: Type: text/plain, Size: 4879 bytes --]

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 george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

[-- Attachment #2: kgdb-dwarf2-2.6.0-1.0.patch.gz --]
[-- Type: application/x-gzip, Size: 11623 bytes --]