Grrr: Kgdb on Linux

Date: Sat, 26 Aug 1995 17:14:49 -0700
From: Pete Delaney <pete@RockyMountain.rahul.net>
On SunOS I/We weren't sucessfull with placing breakpoints in the kernel
till after startup copyies the temporary PTE's and the kernel is fully
mapped. It really limits the value of gdb for a non-trival number of kernel
problems. How did you set things up on Linux?
I fire the first breakpoint right when the low level head.S bootup
code is finished and C-code is callable, it was very trivial and I did
it in one evening. I see no reason why once the kerenel has "some"
mapping in high addresses that it necessitates temporary PTE creation
before breakpoints can work properly, perhaps you are leaving data
bombs in the cache or something. That was the initial problem I ran
into while trying to get it to work, flush the cache after setting a
breakpoint and/or changing kernel memory or die ;-)
Also note that the way things are set up, kgdb and kadb can co-exist,
so you can do real low-level boot-up trap entry assembly code
debugging with kadb and still set kgdb breakpoints etc. They use
different traps so they won't get in each others way.
Another problem, and this is generic, is that gdb tries to predict
where execution could possibly flow after one instruction or one
c-statement or whatever, and thus can set a LOT of breakpoints. If it
decides that your call into the prom's address space would need a
breakpointe to get what it wanted it will try to write to PROM's text
in ROM. This is a fundamental problem with kgdb because it has no
concept of "I may execute here but you can't set break points
mr. debugger" I have a work around that involves making the PROM
writable and giving it's text image a place in ROM, in fact I think I
know a way to completely eliminate the prom once I have a copy of it's
device tree if I can deceipher enough of it's guts.
In all, kgdb support was the easiest thing I ever added to the Sparc
kernel to date, no kidding, all of 8 hours of relaxing hack, and
approx 4 cups of coffee. A day in the park... ;-)
Later,
David S. Miller
davem@caip.rutgers.edu