I will answer your questions from the beginning:
> When can you use gdb -k?I believe in newer versions of bsd release we've moved from
> With the latest GDB from CVS, I get:
> $ gdb -k
> gdb: unrecognized option `-k'
> Run gdb ( like this ) : kgdb -a -a -a kernel.debugYes. I get the above, but is that an issue ?
> (kgdb) target remote /dev/cuad0
kgdb requires either a core file or a device file for remote
debugging. If we issue this command on a local machine this
behavior is pretty straightforward, with no quirkiness.
> I guess you mean Emacs now parses your command line now.
& gt; But presumably you still get *gud-cuad0* in the mode-line of the GUD
> buffer.
> Thank you very much Nick, Your clue of emacs version prompted me
> to upgrade my emacs. after which I'm able to do it.
I guess you mean Emacs now parses your command line now.
But presumably you still get *gud-cuad0* in the mode-line of the GUD
buffer.
> BTW, my earlier emacs version was 21.2.4 and now it is 22.0.50.1
>
> One more question: I'm still not able to open the file another emacs
> window. I thought this was supposed happen automatically. In other
> instances of emacs ( lik e when debugging apps ) the source code file
> opens automatically in another emacs window ( vertical split style).
I have some more thoughts but you need to answer my questions for good
communication.
Does kgdb work like gdb?
Is "target remote /dev/cuad0" a valid kgdb command?
> Even if it doesn't, when I enter "f" it opens up automatically.
For the source to appear gdb/kgdb must output annotations. In gdb, this
requires "--fullname" or "-annotate=1" for text mode and "-annotate=3"
for graphical mode. In Emacs 21 "--fullname" was used but was not visible
to the user.
In Emacs 22, running an app like this:
Run gdb (like this): gdb myprog
won't display the source, but:
Run gdb (like this): gdb -annotate=3 myprog
will. Likewise, I suspect
Run gdb ( like this ) : kgdb -r /dev/cuad0 kernel.debug
won't display the source, but:
Run gdb ( like this ) : k gdb -a -a -a -r /dev/cuad0 kernel.debug
will.
> One possibility is, though i changed the emacs current directory
> to /usr/obj/usr/src/sys/MYKERNEL/ , the -r /dev/cuad0 option would have
> changed the default directory, as evident in the file line when a gud
> window is opened:
> Current directory is /dev/
> :(
You really want to find another way of specifying the arguments along the lines
that I suggested, so that the directory doesn't change and you get
*gud-kernel.debug* in the mode-line of the GUD buffer. However, I think
another way to stop the current directory from changing is to set
gud-chdir-before-run to nil.
One last thing, if you do get it to work well, please e-mail me what you
have learnt so that I can add it to my homepage.
Thanks,
Nick http://www.inet.net.nz/~nickrob