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've been following your thoughts but haven't replied because I don't have
any particular ideas beyond what you've said. The main things I would say
are to build off the existing SE-mode data structures and make the tracing
work with SE mode as well, but you've already covered those. You'll see
...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf
Of Steve Reinhardt
Sent: Friday, January 30, 2009 10:12 AM
To: M5 Developer List
Subject: Re: [m5-dev] syscall tracer
I've been following your thoughts but haven't replied because I don't have
any particular ideas beyond what you've said
Quoting Geoffrey Blake bla...@umich.edu:
What exactly are you trying to do with making a syscall tracer Gabe? I
thought your original problem was a happening with GLIBC doing some bizarre
pointer encryption/decryption and it was getting it wrong leading to a
segmentation fault?
That is the
Actually the timer goes off and the UART gets checked manually, and
everything has passed through by that point so execution continues. I
think there's supposed to be an interrupt or something for when the UART
finishes, so there may be an issue with that never showing up.
Gabe Black wrote:
Anybody? I was thinking one option would be to extend SyscallDesc to
have a gatherArgs() function and a describe() function. describe() would
just generate a string which would be like disassembly but for syscalls.
Then, every syscall would have a nice line in SE with the syscall
traceflag,
Unfortunately, decreasing the TLB size to one was a red haring
(sic?). With only one entry, if an instruction or an access spans pages
(which takes amazingly long to happen), the TLB thrashes back and forth
in that one entry and never gets anywhere. Now what I'm trying to do to
get a
