![]() | |||||||||||||
Messages in this thread |
Amit S. Kale wrote: > On Wednesday 03 Mar 2004 5:22 am, George Anzinger wrote: > >>Andrew Morton wrote: >> >>>George Anzinger <george@mvista.com> wrote: >>> >>>>Often it is not clear just why we are in the stub, given that >>>>we trap such things as kernel page faults, NMI watchdog, BUG macros and >>>>such. >>> >>>Yes, that can be confusing. A little printk on the console prior to >>>entering the debugger would be nice. >> >>That assumes that one can do a printk and not run into a lock. Far better >>IMNSHO is to provide a simple way to get it from gdb. One can then even >>provide a gdb macro to print the relevant source line and its surrounds. I >>my lighter moments I call this the comefrom macro :) In my kgdb it would >>look like: >> >>l * kgdb_info.called_from > > > How about echoing "Waiting for gdb connection" stright into the serial line > without any encoding? Since gdb won't be connected to the other end, and many > a times a minicom could be running at the other end, it'll give a user an > indication of kgdb being ready. Uh, different solution for a different problem. The above command to gdb causes the source code around the location "kgdb_info.called_from" to be displayed. In the -mm version, this is location is filled in by kgdb with the return address for the "kgdb_handle_exception()". This allows you to see just why you are in kgdb. -- 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 13:01 [from the cache] ©2003-2008 | |||||||||||||