I think I'm missing the high level overview of what this thread is
about, but I do have one comment
To help find that seg fault, I'd suggest going into the kernel and placing
m5_exit() calls in arch/x86/mm/fault.c in the do_page_fault() where the
kernel sends a SIGSEGV to user code and that'll
Another thing that could be nice for debugging is hacking ld.so a
little bit so that it passes the symbols to M5 with the add_symbol
instruction. You'd of course not want all instances of ld.so running
to do this, so you'd want to be able to have a set of programs or PIDs
or something that
It would be nice to hack the kernels elf loader to do something
similar as well. Both could provide be sort of an overlay symbol table
you'd pull in and out on task switches. I like these ideas, but
unfortunately the binaries I'm dealing with in my disk image don't seem
to have any symbols
I'm revamping the way I've had interrupt lines implemented in my patch
queue and I have a few questions.
First I'll describe how it used to (and does in the head) work. There is
an interrupt pin which knows what object it belongs to and what its
index is. To connect the timer to the PIC's
This seems like a lot of complexity for not much gain. Remember, that
we don't have to do exactly what the real hardware does. We can have
PIC/IO APIC device that handles both modes. While it needs to appear
to the OS in the correct fashion, it doesn't need to actually be
exactly the same
Those later schemes I agree are overly complex. The PIC and IO APIC
aren't two different modes, they're two different resources the OS can
use at the same time. I think Linux attempted to do just that to try to
work around some aspect of my hardware that wasn't behaving right,
although their
