Marcel Moolenaar wrote:
>
> On Nov 1, 2006, at 10:45 AM, Julian Elischer wrote:
>
>> marcel, jhb suggested I ask you the correct way to revert to
>> ddb once entering gdb?
>
> There's no correct way as far as I know. We (the collective) haven't
> come up with anything yet. It should be easy enough to add a command
> to kgdb that switches the KDB backend, by updating kernel memory. A
> more generic approach would be to have kgdb set a function pointer of
> a function that is to be called before the kernel resumes. This could
> be a function that switches the KDB backend or something else.
>
>> also, what is the reason for kgdb?
>
> I created kgdb to avoid having a lot of gdb patches, which would make
> future imports of GDB hard. By using a binary that links against libgdb,
> it's possible to customize and implement support for kernel debugging
> without having to put that knowledge into the core GDB code.
>
> For example, with kgdb it's easy to debug a crashed kernel. You only
> have to specify the vmcore file number with the -n option and kgdb
> will find the corresponding kernel. You cannot have this level of
> user-friendliness without major patches if you don't have a binary.
>
> The thread debugging support that David Xu implemented is a perfect
> example of why we should not patch GDB: We cannot upgrade GDB at the
> moment without also breaking thread debugging. As such, we're in the
> same corner we were in before I upgraded GDB...
this should be in the docs somewhere..
:-)
BTW I like to run xgdb when debugging the kernel
as a front-end to gdb but it needs to be fixed to handle kgdb
whenever I try it :-)
rarely look at crashdumps. I usually end up using live remote debugging.
This seems a bit 'delicate' at the moment.
>
> FYI,
>
_______________________________________________
freebsd-doc@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-doc
To unsubscribe, send any mail to "freebsd-doc-unsubscribe@freebsd.org"