Re: oskit-mach debugging log
> In reference to compiling oskit / oskit-mach
>
> Should I perhaps use gcc-3.0 ?? Disable optimization ?
I would not recommend either of those, especially for the oskit. It's not
unlikely that the linux driver code in the oskit won't compile properly if
you try either one of these. The proven method is to use gcc 2.95.x and -O2.
> Also, I think if I just run the kernel, it will go somewhat beyond where
> it crashes on the debugging log before it reboots. Maybe that has
> something to do with pipelined instructions? I'll see if I can trace
> that as well.
It's definitely the case that the single-stepping trap and the gdb stub
running in between some of these special setup instructions could get
dicey. I'm not sure everything is kosher at all points in the middle of
the sequences of modifying descriptors, reloading segment registers, and so
forth. So you'll have to play around with gdb or other debugging
techniques (inserting printfs, or direct asm to write to your vga) to find
the exact spots of badness and where before and after them it is really
safe to stop and inspect.
> Also, how/can I view the registers on the 2nd cpu using gdb?
The stub talking on the serial line is only ever running on one CPU at a
time. The base_critical_enter/base_critical_leave calls in
oskit/kern/gdb_serial.c are there to ensure this stays reasonably sane.
Each CPU that hits a trap that should go to gdb will call the oskit
function `gdb_trap' (via kernel_trap). If the segments or IDT or whatnot
is too fouled up to get to the trap handlers properly (through the locore.S
code to kernel_trap in i386/i386/trap.c), then you are SOL. If kernel
traps are working on that CPU, then it will get into teh gdb_serial.c code
and do base_critical_enter. If another CPU is already in that code, the
second CPU will spin until the first one finishes and calls
base_critical_leave. So once you get a CPU talking to gdb, you will keep
talking to the same CPU until gdb tells it to continue running (at which
time the other CPU can come in and talk to gdb). (There are hooks into the
gdb code that we could use to write SMP-aware code that would report each
CPU to gdb as a separate thread so you could use the gdb thread commands to
select the CPU. But that would be a bit of hacking, and it would rely on
the IPIs working right and such--not really a way to debug the SMP setup
itself.)
Reply to: