> 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.)
