Mathur, Shobhit wrote:
>
>
> Hello,
>
> BACKGROUND:
>
> I was keen to see kgdb running for purely academic reasons. Thus,
> I made a setup of 2 machines for source-level debugging of the
> linux-kernel. The procedure mentioned on the web-site
> [ kgdb.sourceforge.net] has been adhered to. I was able to
> successfully configure the setup. Also, I decided to use "ddd" front-end
> on gdb [local m/c] for debugging the kgdb-patched kernel on the remote
> machine, which is the usual setup for such debugging-efforts.
> The m/c to be debugged stops with the message "Waiting for
> connection from remote gdb..." until the "target remote" command is run
> from the "gdb" prompt of "ddd", upon which the m/c to be debugged
> continues it's bootup till it shows the command-prompt.
>
> PROBLEM:
>
> I was interested in setting a break-point in start_kernel thru' "ddd"
> such that the boot-up of the m/c to be debugged could be analysed
> step-by-step remotely. Though, I am able to set the breakpoint in
> start_kernel(),
> the commands "run" or "continue" on the "gdb" prompt, only throw up the
> following errors :
>
> (gdb) info break
> Num Type Disp Enb Address What
> 7 breakpoint keep y 0xc027e7f0 in start_kernel at
> init/main.c:614
> (gdb) run
The "run" command should not be used. Kgdb/gdb debugging of the
kernel is more like attaching to a running program than running it.
When you use the run command you are telling gdb to, among other
things, transfer conrol to the beginning of the program, which in the
case of the kernel, is where the boot loader jumps on boot. In the
kernel this code in is memory that is released to free memory on the
way up.
If you make this mistake often I recommend the following gdb macro:
define hook-run
echo "run is not available for kernel debugging \n"
p .
end
The "p ." will error out the command and snach you from the jaws of
reboot/ fsck :)
This macro should be in .gdbinit file in the same directory as the
vmlinux file.
> warning: shared library handler failed to enable breakpoint
> warning: Cannot insert breakpoint 7:
> Cannot access memory at address 0xc027e7f0
>
> QUESTION:
>
> I very strongly suspect that this exercise follows a particular sequence
> of steps to get it right. Either I am missing some step or I am not
> following the "order". In either case, I would be glad to receive some
> help/comments on my academic endeavour to be able to remotely debug the
> kernel.
>
> - Kindly let me know a solution
>
> - TIA
>
> - Shobhit Mathur
> -
> 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/
>
-- 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/
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 22:00:23 EST