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

[George Anzinger <george@mvista.com>]

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