![]() | |||||||||||||
Messages in this thread |
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 [unhandled content-type:application/x-gzip] | ||||||||||||
| Last update: 2005-03-22 13:01 [from the cache] ©2003-2008 | |||||||||||||