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, but it would also automatically be available in FS for my tracer. gatherArgs would just populate member variables (for instance) with the syscall arguments so they aren't pulled in for both the description and the actual syscall. It wouldn't be necessary, especially considering that syscalls aren't a very performance sensitive operation for us.
Gabe Gabe Black wrote: > 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: > >> As a vote in favor of the usefulness of something like this, I think >> I've identified -a- problem with it. There's a close system call that's >> called on file descriptor 0 which is connected to the UART. The kernel >> starts waiting for the buffer to drain, but it never does for some >> reason and it just wakes up every now and then to give it another shot. >> I don't know if this has anything to do with the segfault, but I'd guess >> this is partially from me implementing all interrupts like they're edge >> triggered rather than level triggered like the UART apparently expects. >> If the UART starts driving its interrupt line while they're disabled for >> some reason, that will get lost and some count could end up out of >> balance. I'm going to be working on my somewhat hacky interrupt wiring >> scheme to make it less hacky and something I'm willing to push, and in >> the process I'll probably try to fix this too. >> >> To the folks with more kernel experience than me, does that sound >> like a reasonable theory? Is there something else that might make it >> wait forever? It seems to think it's got 7 characters in the buffer >> which seems like a very small number compared to how much output it's >> generated. >> >> Gabe >> >> Gabe Black wrote: >> >> >>> 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 better handle on the flow of the program is to implement a tracer, >>> like the one you get with the Exec traceflag, but that prints out the >>> parameters and return value of system calls. I have a simple version of >>> this hacked in already, but there are probably four things that prevent >>> it from working as well as it could. Three of those are mapping syscall >>> numbers to names, knowing how many arguments there are, and knowing >>> which are string pointers so the string can be gathered with functional >>> accesses. The fourth is identifying when you're entering or exiting a >>> syscall in the first place. For the first group, I'm just simply >>> ignoring those issues and printing the raw syscall number and the values >>> in each of the argument registers. For the last one, I'm doing a >>> hardcoded check for the mnemonics of fitting instructions as they go by >>> which you can imagine is hardly efficient or flexible. >>> >>> At least some of the information I'd like to get at, like syscall >>> names at least, is already present in m5 but is only compiled in for SE. >>> Other bits of information like the number and types of arguments would >>> be harder to get at. I was thinking for system call and system return >>> instructions the IsSyscall and IsReturn and/or IsCall could be used to >>> generically identify the instructions of interest. Does anyone have any >>> thoughts about whether this is worthwhile and how best to get the >>> information it would need gathered together? >>> >>> Gabe >>> _______________________________________________ >>> m5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >>> >>> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> >> > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
