On Thu, Aug 24, 2006 at 09:19:49AM -0400, Vivek Goyal wrote: > On Thu, Aug 24, 2006 at 04:42:59PM +0530, Rachita Kothiyal wrote: > > > > > > But as of now there are few issues with "gdb bt" > > > > 1) Sometimes the no. of stack frames displayed doesn't end for a long time > > and also the "q" command doesn't work as desired once the screen is full. > > The workaround is to give some limiting count like "gdb bt 10". > > I tried gdb ver 6.1 externally (outside crash) also and see the same > > long ending stack frames where as the latest gdb (ver 6.4), works fine. So > > just wondering if you are planning to upgrade embedded gdb to ver 6.4? > > > > 2) As unlike crash, there is no concept of tasks in gdb, we can only see the > > backtraces for tasks active at the time of crash. > > I guess, we will continue to have both the backtracing mechanisms. I am > assuming that this approach does not disable crash's bt mechanism. Its > kind of add on? So a user can use crash bt mechanism for backtraces of > tasks which are not currently running on some cpu. That's right Vivek. Crash bt is also available. So if you say 'bt' on crash prompt you get the backtrace via crash, and if you say 'gdb bt' on crash prompt you will get the gdb backtrace. Thanks Rachita -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
