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 help track down when it > happens the first time, and reduce the cruft that happens after the program > halts, like printing "Segmentation Fault" to the serial port. I'm not sure > a syscall tracer will help with finding the segfault, I have a feeling its > all in glibc and some weird corner case in the ISA of the M5 implementation > that is causing the bug. This version of glibc causing the fault does work > on real hardware correct? I'm not sure what this segfault is all about, but an alternative to m5_exit is that we could create a breakpoint instruction and allow it to take a parameter as a breakpoint number. This way, M5 could generally run ignoring the breakpoints, unless you turn them on. The breakpoint could also be a string which refers to a traceflag. An abuse of the traceflags mechanism, but not so bad. 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 this happened on. Just some thoughts. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
