[m5-dev] Cron m5t...@zizzer /z/m5/regression/do-regression quick
* build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. See /z/m5/regression/regress-2009-01-30-03:00:01 for details. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
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. 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 that there is some cheesy SE-mode tracing that simply prints the first 3 args as ints (or something like that), which was basically as much effort as I was willing to put into it. It does sound very useful though. One idea that just came to mind is that it might be worth looking at the strace source to see if there are any ideas there you can use. Better to look at the BSD one rather than the Linux one of course in case there is code that you want to re-use directly. Steve On Thu, Jan 29, 2009 at 11:54 PM, Gabe Black gbl...@eecs.umich.edu 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, 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 m5-dev@m5sim.org
Re: [m5-dev] syscall tracer
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? 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? Geoff From: m5-dev-boun...@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. 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 that there is some cheesy SE-mode tracing that simply prints the first 3 args as ints (or something like that), which was basically as much effort as I was willing to put into it. It does sound very useful though. One idea that just came to mind is that it might be worth looking at the strace source to see if there are any ideas there you can use. Better to look at the BSD one rather than the Linux one of course in case there is code that you want to re-use directly. Steve On Thu, Jan 29, 2009 at 11:54 PM, Gabe Black gbl...@eecs.umich.edu 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, 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
Re: [m5-dev] Idea for error messages
Yea I thought about that. Pretty much if you update an error message, you need to move the old hash to the new hash on the wiki. Ali On Jan 30, 2009, at 2:48 AM, Gabe Black wrote: That sounds like a good idea, but what if I had panic(Soemthing bad) and changed it to panic(Something bad)? They'd be the same thing but with different hashes. Gabe Ali Saidi wrote: We've talked for a while about needing better error messages, links, more descriptions on the website, etc. How about we modify panic(), fatal(), and warn() to hash the format string for the message and print out a url with some portion of that hash. So: fatal(Parameter %s.%s was not specified) would turn into: Fatal: Parameter foo.bar was not specified See http://www.m5sim.org/wiki/index.php/9c6d054cbec3 As people asked questions we could populate the hashes with answers in the wiki. (We could also use url re-writing to make the url a bit smaller). Thoughts? Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Idea for error messages
Anyone else? To make this work we would either have to include a md5 algorithm is base (I found a BSD licensed one) or require libopenssl. Ali On Jan 30, 2009, at 11:52 AM, Ali Saidi wrote: Yea I thought about that. Pretty much if you update an error message, you need to move the old hash to the new hash on the wiki. Ali On Jan 30, 2009, at 2:48 AM, Gabe Black wrote: That sounds like a good idea, but what if I had panic(Soemthing bad) and changed it to panic(Something bad)? They'd be the same thing but with different hashes. Gabe Ali Saidi wrote: We've talked for a while about needing better error messages, links, more descriptions on the website, etc. How about we modify panic(), fatal(), and warn() to hash the format string for the message and print out a url with some portion of that hash. So: fatal(Parameter %s.%s was not specified) would turn into: Fatal: Parameter foo.bar was not specified See http://www.m5sim.org/wiki/index.php/9c6d054cbec3 As people asked questions we could populate the hashes with answers in the wiki. (We could also use url re-writing to make the url a bit smaller). Thoughts? Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Idea for error messages
Would we need such a strong hash? A dumb CRC would likely be sufficient if that would be easier to bring in. Gabe Ali Saidi wrote: Anyone else? To make this work we would either have to include a md5 algorithm is base (I found a BSD licensed one) or require libopenssl. Ali On Jan 30, 2009, at 11:52 AM, Ali Saidi wrote: Yea I thought about that. Pretty much if you update an error message, you need to move the old hash to the new hash on the wiki. Ali On Jan 30, 2009, at 2:48 AM, Gabe Black wrote: That sounds like a good idea, but what if I had panic(Soemthing bad) and changed it to panic(Something bad)? They'd be the same thing but with different hashes. Gabe Ali Saidi wrote: We've talked for a while about needing better error messages, links, more descriptions on the website, etc. How about we modify panic(), fatal(), and warn() to hash the format string for the message and print out a url with some portion of that hash. So: fatal(Parameter %s.%s was not specified) would turn into: Fatal: Parameter foo.bar was not specified See http://www.m5sim.org/wiki/index.php/9c6d054cbec3 As people asked questions we could populate the hashes with answers in the wiki. (We could also use url re-writing to make the url a bit smaller). Thoughts? Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Idea for error messages
I would be worried that the collision probability would be too high with a crc. Ali On Jan 30, 2009, at 1:46 PM, Gabe Black wrote: Would we need such a strong hash? A dumb CRC would likely be sufficient if that would be easier to bring in. Gabe Ali Saidi wrote: Anyone else? To make this work we would either have to include a md5 algorithm is base (I found a BSD licensed one) or require libopenssl. Ali On Jan 30, 2009, at 11:52 AM, Ali Saidi wrote: Yea I thought about that. Pretty much if you update an error message, you need to move the old hash to the new hash on the wiki. Ali On Jan 30, 2009, at 2:48 AM, Gabe Black wrote: That sounds like a good idea, but what if I had panic(Soemthing bad) and changed it to panic(Something bad)? They'd be the same thing but with different hashes. Gabe Ali Saidi wrote: We've talked for a while about needing better error messages, links, more descriptions on the website, etc. How about we modify panic(), fatal(), and warn() to hash the format string for the message and print out a url with some portion of that hash. So: fatal(Parameter %s.%s was not specified) would turn into: Fatal: Parameter foo.bar was not specified See http://www.m5sim.org/wiki/index.php/9c6d054cbec3 As people asked questions we could populate the hashes with answers in the wiki. (We could also use url re-writing to make the url a bit smaller). Thoughts? Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Idea for error messages
Yea, since these only get printed when an error occurs, performance shouldn't be an issue. Steve On Fri, Jan 30, 2009 at 10:48 AM, Ali Saidi sa...@umich.edu wrote: I would be worried that the collision probability would be too high with a crc. Ali On Jan 30, 2009, at 1:46 PM, Gabe Black wrote: Would we need such a strong hash? A dumb CRC would likely be sufficient if that would be easier to bring in. Gabe Ali Saidi wrote: Anyone else? To make this work we would either have to include a md5 algorithm is base (I found a BSD licensed one) or require libopenssl. Ali On Jan 30, 2009, at 11:52 AM, Ali Saidi wrote: Yea I thought about that. Pretty much if you update an error message, you need to move the old hash to the new hash on the wiki. Ali On Jan 30, 2009, at 2:48 AM, Gabe Black wrote: That sounds like a good idea, but what if I had panic(Soemthing bad) and changed it to panic(Something bad)? They'd be the same thing but with different hashes. Gabe Ali Saidi wrote: We've talked for a while about needing better error messages, links, more descriptions on the website, etc. How about we modify panic(), fatal(), and warn() to hash the format string for the message and print out a url with some portion of that hash. So: fatal(Parameter %s.%s was not specified) would turn into: Fatal: Parameter foo.bar was not specified See http://www.m5sim.org/wiki/index.php/9c6d054cbec3 As people asked questions we could populate the hashes with answers in the wiki. (We could also use url re-writing to make the url a bit smaller). Thoughts? Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Idea for error messages
On Jan 30, 2009, at 2:53 PM, nathan binkert wrote: We've talked for a while about needing better error messages, links, more descriptions on the website, etc. How about we modify panic(), fatal(), and warn() to hash the format string for the message and print out a url with some portion of that hash. This is a pretty cool idea. The only realistic alternative is to give error codes to the various functions. It's more work up front, but it means that we don't need to do anything if the actual message changes. I'm sure a little perl magic could assign error codes to all instances of these calls in the source tree. Of course, one would have to be careful not to duplicate the error codes. Yea, and with distributed development this is also a bit of a pain as well. What happens if two people assign the same error code. I'd probably lean towards Ali's proposal due to its simplicity, but I think we'd need to run ispell on all of the messages to make sure that they're ok and I think we also need to find out how many duplicates we have because the same message is in multiple places. Yes. I don't think we have many duplicates, at least not when the the messages are meaningful. panic(crap) isn't at all helpful. One final thing, is there a way to have a default page pop up to explain that the error message has not yet been written about and to give instructions? Maybe URL rewriting can do that sort of thing too? Certainly if rewrite can run a snippet of python code or something else, it could. I suggest putting the error messages in a different directory (e.g. m5sim.org/e/error id). With this we could either re-write to the normal wiki, re-write to another wiki for errors where we had a custom not-found page, or re-write to some php/python that checked and did the appropriate thing. Either way not putting /wiki/index.php? error_id gives us many possibilities. While you're at it, I created an info() that is just like warn(), there are probably things that should be converted so people don't keep wondering about them. Yea, I was thinking that too... Although I don't see info in the repository. Have you added it? Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Idea for error messages
I suggest putting the error messages in a different directory (e.g. m5sim.org/e/error id). With this we could either re-write to the normal wiki, re-write to another wiki for errors where we had a custom not-found page, or re-write to some php/python that checked and did the appropriate thing. Either way not putting /wiki/index.php? error_id gives us many possibilities. This all sounds great. While you're at it, I created an info() that is just like warn(), there are probably things that should be converted so people don't keep wondering about them. Yea, I was thinking that too... Although I don't see info in the repository. Have you added it? It's called inform() because I think info was used as a variable name in several places. I've also added hack(). The idea behind inform() is that it is for informative messages that users should know, but not worry about. hack() is for things like watch out, this doesn't work right Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Idea for error messages
I'd probably lean towards Ali's proposal due to its simplicity, but I think we'd need to run ispell on all of the messages to make sure that they're ok and I think we also need to find out how many duplicates we have because the same message is in multiple places. Yes. I don't think we have many duplicates, at least not when the the messages are meaningful. panic(crap) isn't at all helpful. And conversely if panic(Useful error message) shows up in more than one place, it would ideally have the same explanation on the same wiki page. People would need to try to be consistent with each other as far as the exact text goes though. One thing we should consider is the fact that not everyone will be using the same version of the source. If a message changes and we move the page, the old message could still be out there but have no explanation. If old wiki pages live forever that may start to get crowded. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Idea for error messages
One thing we should consider is the fact that not everyone will be using the same version of the source. If a message changes and we move the page, the old message could still be out there but have no explanation. If old wiki pages live forever that may start to get crowded. Good point... so if a message changes, we probably want to just add a new link to the same page, not copy or move the existing page. One mitigating factor will be that I expect most message updates would be to make the message to be more descriptive or informative, but if we can put the additional detail on the wiki page instead then perhaps updating the message itself will be less necessary. The one case where that might not be true is if we update the message to print additional run-specific information about the error cause (e.g., values of variables); you could think of designing the hash in such a way that minor changes wouldn't disturb it (e.g., strip out all the %s/%d codes before hashing, only hash the first N characters or up to the first colon, or something like that), but (1) it'd probably be hard to find something that works universally and (2) I feel like we're starting to overengineer this idea. We should also start the practice of listing all the error message(s) right at the top of the wiki page as a consistency check. This would also let us handle hash collisions (if any) just by having separate sections on the same page. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Idea for error messages
On Jan 30, 2009, at 5:02 PM, Steve Reinhardt wrote: One thing we should consider is the fact that not everyone will be using the same version of the source. If a message changes and we move the page, the old message could still be out there but have no explanation. If old wiki pages live forever that may start to get crowded. Good point... so if a message changes, we probably want to just add a new link to the same page, not copy or move the existing page. One mitigating factor will be that I expect most message updates would be to make the message to be more descriptive or informative, but if we can put the additional detail on the wiki page instead then perhaps updating the message itself will be less necessary. The one case where that might not be true is if we update the message to print additional run-specific information about the error cause (e.g., values of variables); you could think of designing the hash in such a way that minor changes wouldn't disturb it (e.g., strip out all the %s/%d codes before hashing, only hash the first N characters or up to the first colon, or something like that), but (1) it'd probably be hard to find something that works universally and (2) I feel like we're starting to overengineer this idea. We should also start the practice of listing all the error message(s) right at the top of the wiki page as a consistency check. This would also let us handle hash collisions (if any) just by having separate sections on the same page. So.. In this case I think simpler is better, because it will get done. If we over-engineer it, it won't. I'll have the changes made in an hour this way. Pages should certainly be linked and not moved. The wiki provides some way to do a redirection automatically. I agree that we should list the error messages at the top of the page. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] syscall tracer
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 base problem. What I was doing manually was that since the binary is dynamically linked, I was searching for system calls in the Exec trace to find where the dynamic linker had mmapped slabs of init and libc. That was/is the only way to know that something like 0x28faff0ac850 really goes with 0x850 in the linker (or init or libc? I forget). There are patterns, but they're hard to remember and they were actually changing when I tried the small TLB size. Address space randomization seems to be sensitive to small changes in execution, so unless I was just changing the trace flags I'd have to figure out the mappings all over again. Then it occurred to me there was an easy way to automate part of that process which is where this part came from. 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 assuming it works on real hardware. The image I'm using is the starter file system for Gentoo, so if it didn't work there'd be a lot of annoyed people. What I did was add a trace flag for all faults in x86. Since there are no tlb miss faults, or at least those work different, the only ones that should show up are the page faults. That let me home in on the exact instruction at fault, and then though a lot of painful pattern matching find the C that spawned it. I think there's some sort of address mapping issue because the thing that set the pointer that's being garbled appears to be constructing a linked list for the heap manager. Obviously those two things shouldn't land on top of each other. Fortunately, I found the code that manipulates that as well. Unfortunately I forgot where it was, so I'll have to dumpster dive again. What I'm going to do is to find the actual address used in both cases, fortunately a statically defined global address in the faulting case, and try to figure out which one is in the wrong for using it. It's possible they both are right and the kernel is mistakenly mapping the same physical page to both addresses. In that case it'll be a little more fun to figure out, but at least I'll be working with debug information and letting gdb do the heavy lifting. It's also possible that the kernel is mapping everything right and my page table walker or TLB code is tripping things up. Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Idea for error messages
The quick thing to do is to just modify the page not found message on the wiki. Does this work for everyone for now? In the future we could do something more complex to check the wiki (there is an api) and then display a special page if we want. Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Idea for error messages
The quick thing to do is to just modify the page not found message on the wiki. Does this work for everyone for now? In the future we could do something more complex to check the wiki (there is an api) and then display a special page if we want. This would affect all wiki pages, right? I guess as an immediate thing Can I also suggest that you use panic/fatal/warn/info/hack in the url somehow? This would help us create better default pages in the future. Though that would suggest that we should migrate things to the proper name before we get going. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Config: Cause a fatal() when a parameter withou...
changeset 2831ae658bfc in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=2831ae658bfc description: Config: Cause a fatal() when a parameter without a default value isn't set(FS #315). diffstat: 3 files changed, 4 insertions(+), 2 deletions(-) src/cpu/BaseCPU.py |2 +- src/dev/DiskImage.py |1 + src/python/m5/SimObject.py |3 ++- diffs (33 lines): diff -r dad5aad2dc2d -r 2831ae658bfc src/cpu/BaseCPU.py --- a/src/cpu/BaseCPU.pyThu Jan 29 22:27:11 2009 -0800 +++ b/src/cpu/BaseCPU.pyFri Jan 30 19:08:13 2009 -0500 @@ -69,7 +69,7 @@ function_trace = Param.Bool(False, Enable function trace) function_trace_start = Param.Tick(0, Cycle to start function trace) -checker = Param.BaseCPU(checker CPU) +checker = Param.BaseCPU(NULL, checker CPU) do_checkpoint_insts = Param.Bool(True, enable checkpoint pseudo instructions) diff -r dad5aad2dc2d -r 2831ae658bfc src/dev/DiskImage.py --- a/src/dev/DiskImage.py Thu Jan 29 22:27:11 2009 -0800 +++ b/src/dev/DiskImage.py Fri Jan 30 19:08:13 2009 -0500 @@ -42,3 +42,4 @@ child = Param.DiskImage(RawDiskImage(read_only=True), child image) table_size = Param.Int(65536, initial table size) +image_file = diff -r dad5aad2dc2d -r 2831ae658bfc src/python/m5/SimObject.py --- a/src/python/m5/SimObject.pyThu Jan 29 22:27:11 2009 -0800 +++ b/src/python/m5/SimObject.pyFri Jan 30 19:08:13 2009 -0500 @@ -748,7 +748,8 @@ for param in param_names: value = self._values.get(param) if value is None: -continue +m5.fatal(%s.%s without default or user set value \ +% (self.path(), param)) value = value.getValue() if isinstance(self._params[param], VectorParamDesc): ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Errors: Print a URL with a hash of the format s...
changeset 05ffa2c3c800 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=05ffa2c3c800
description:
Errors: Print a URL with a hash of the format string to find more
information about an error.
diffstat:
7 files changed, 47 insertions(+), 21 deletions(-)
configs/common/Simulation.py | 20 ++--
configs/example/fs.py|4 ++--
configs/example/se.py|2 +-
src/base/misc.cc | 14 ++
src/python/m5/SimObject.py |4 ++--
src/python/m5/__init__.py| 20
src/python/m5/params.py |4 ++--
diffs (231 lines):
diff -r 2831ae658bfc -r 05ffa2c3c800 configs/common/Simulation.py
--- a/configs/common/Simulation.py Fri Jan 30 19:08:13 2009 -0500
+++ b/configs/common/Simulation.py Fri Jan 30 20:04:15 2009 -0500
@@ -78,10 +78,10 @@
cptdir = getcwd()
if options.fast_forward and options.checkpoint_restore != None:
-m5.panic(Error: Can't specify both --fast-forward and
--checkpoint-restore)
+m5.fatal(Error: Can't specify both --fast-forward and
--checkpoint-restore)
if options.standard_switch and not options.caches:
-m5.panic(Error: Must specify --caches when using --standard-switch)
+m5.fatal(Error: Must specify --caches when using --standard-switch)
np = options.num_cpus
max_checkpoints = options.max_checkpoints
@@ -129,7 +129,7 @@
# Fast forward to a simpoint (warning: time consuming)
elif options.simpoint:
if testsys.cpu[i].workload[0].simpoint == 0:
-m5.panic('simpoint not found')
+m5.fatal('simpoint not found')
testsys.cpu[i].max_insts_any_thread = \
testsys.cpu[i].workload[0].simpoint
# No distance specified, just switch
@@ -163,7 +163,7 @@
if options.simpoint:
for i in xrange(np):
if testsys.cpu[i].workload[0].simpoint == 0:
-m5.panic('no simpoint for testsys.cpu[%d].workload[0]' % i)
+m5.fatal('no simpoint for testsys.cpu[%d].workload[0]', i)
checkpoint_inst = int(testsys.cpu[i].workload[0].simpoint) +
offset
testsys.cpu[i].max_insts_any_thread = checkpoint_inst
# used for output below
@@ -183,13 +183,13 @@
import re
if not isdir(cptdir):
-m5.panic(checkpoint dir %s does not exist! % cptdir)
+m5.fatal(checkpoint dir %s does not exist!, cptdir)
if options.at_instruction:
checkpoint_dir = joinpath(cptdir, cpt.%s.%s % \
(options.bench, options.checkpoint_restore))
if not exists(checkpoint_dir):
-m5.panic(Unable to find checkpoint directory %s % \
+m5.fatal(Unable to find checkpoint directory %s,
checkpoint_dir)
print Restoring checkpoint ...
@@ -198,7 +198,7 @@
elif options.simpoint:
# assume workload 0 has the simpoint
if testsys.cpu[0].workload[0].simpoint == 0:
-m5.panic('Unable to find simpoint')
+m5.fatal('Unable to find simpoint')
options.checkpoint_restore += \
int(testsys.cpu[0].workload[0].simpoint)
@@ -206,8 +206,8 @@
checkpoint_dir = joinpath(cptdir, cpt.%s.%d % \
(options.bench, options.checkpoint_restore))
if not exists(checkpoint_dir):
-m5.panic(Unable to find checkpoint directory %s.%s % \
-(options.bench, options.checkpoint_restore))
+m5.fatal(Unable to find checkpoint directory %s.%s,
+options.bench, options.checkpoint_restore)
print Restoring checkpoint ...
m5.restoreCheckpoint(root,checkpoint_dir)
@@ -226,7 +226,7 @@
cpt_num = options.checkpoint_restore
if cpt_num len(cpts):
-m5.panic('Checkpoint %d not found' % cpt_num)
+m5.fatal('Checkpoint %d not found', cpt_num)
## Adjust max tick based on our starting tick
maxtick = maxtick - int(cpts[cpt_num - 1])
diff -r 2831ae658bfc -r 05ffa2c3c800 configs/example/fs.py
--- a/configs/example/fs.py Fri Jan 30 19:08:13 2009 -0500
+++ b/configs/example/fs.py Fri Jan 30 20:04:15 2009 -0500
@@ -31,7 +31,7 @@
import m5
if not m5.build_env['FULL_SYSTEM']:
-m5.panic(This script requires full-system mode (*_FS).)
+m5.fatal(This script requires full-system mode (*_FS).)
from m5.objects import *
m5.AddToPath('../common')
@@ -105,7 +105,7 @@
elif m5.build_env['TARGET_ISA'] == x86:
test_sys = makeLinuxX86System(test_mem_mode, bm[0])
else:
-m5.panic(incapable of building non-alpha or non-sparc full system!)
+m5.fatal(incapable of building non-alpha or non-sparc full
[m5-dev] changeset in m5: Errors: Use the correct panic/warn/fatal/info m...
changeset 9f7efe90084e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9f7efe90084e
description:
Errors: Use the correct panic/warn/fatal/info message in some places.
diffstat:
4 files changed, 10 insertions(+), 10 deletions(-)
src/arch/sparc/tlb.cc |2 +-
src/sim/process.cc|2 +-
src/sim/simulate.cc |2 +-
src/sim/system.cc | 14 +++---
diffs (84 lines):
diff -r 05ffa2c3c800 -r 9f7efe90084e src/arch/sparc/tlb.cc
--- a/src/arch/sparc/tlb.cc Fri Jan 30 20:04:15 2009 -0500
+++ b/src/arch/sparc/tlb.cc Fri Jan 30 20:04:17 2009 -0500
@@ -1129,7 +1129,7 @@
break;
case ASI_SPARC_ERROR_EN_REG:
case ASI_SPARC_ERROR_STATUS_REG:
-warn(Ignoring write to SPARC ERROR regsiter\n);
+inform(Ignoring write to SPARC ERROR regsiter\n);
break;
case ASI_HYP_SCRATCHPAD:
case ASI_SCRATCHPAD:
diff -r 05ffa2c3c800 -r 9f7efe90084e src/sim/process.cc
--- a/src/sim/process.ccFri Jan 30 20:04:15 2009 -0500
+++ b/src/sim/process.ccFri Jan 30 20:04:17 2009 -0500
@@ -343,7 +343,7 @@
if(stack_base - stack_min 8*1024*1024)
fatal(Over max stack size for one thread\n);
pTable-allocate(stack_min, TheISA::PageBytes);
-warn(Increasing stack size by one page.);
+inform(Increasing stack size by one page.);
};
return true;
}
diff -r 05ffa2c3c800 -r 9f7efe90084e src/sim/simulate.cc
--- a/src/sim/simulate.cc Fri Jan 30 20:04:15 2009 -0500
+++ b/src/sim/simulate.cc Fri Jan 30 20:04:17 2009 -0500
@@ -84,7 +84,7 @@
if (se_event != limit_event) {
assert(limit_event-scheduled());
limit_event-squash();
-warn_once(be nice to actually delete the event here);
+hack_once(be nice to actually delete the event here);
}
return se_event;
diff -r 05ffa2c3c800 -r 9f7efe90084e src/sim/system.cc
--- a/src/sim/system.cc Fri Jan 30 20:04:15 2009 -0500
+++ b/src/sim/system.cc Fri Jan 30 20:04:17 2009 -0500
@@ -95,12 +95,12 @@
* Load the kernel code into memory
*/
if (params()-kernel == ) {
-warn(No kernel set for full system simulation. Assuming you know what
+inform(No kernel set for full system simulation. Assuming you know
what
you're doing...\n);
} else {
// Load kernel code
kernel = createObjectFile(params()-kernel);
-warn(kernel located at: %s, params()-kernel);
+inform(kernel located at: %s, params()-kernel);
if (kernel == NULL)
fatal(Could not load kernel file %s, params()-kernel);
@@ -115,16 +115,16 @@
// load symbols
if (!kernel-loadGlobalSymbols(kernelSymtab))
-panic(could not load kernel symbols\n);
+fatal(could not load kernel symbols\n);
if (!kernel-loadLocalSymbols(kernelSymtab))
-panic(could not load kernel local symbols\n);
+fatal(could not load kernel local symbols\n);
if (!kernel-loadGlobalSymbols(debugSymbolTable))
-panic(could not load kernel symbols\n);
+fatal(could not load kernel symbols\n);
if (!kernel-loadLocalSymbols(debugSymbolTable))
-panic(could not load kernel local symbols\n);
+fatal(could not load kernel local symbols\n);
DPRINTF(Loader, Kernel start = %#x\n, kernelStart);
DPRINTF(Loader, Kernel end = %#x\n, kernelEnd);
@@ -184,7 +184,7 @@
}
if (threadContexts[id])
-panic(Cannot have two CPUs with the same id (%d)\n, id);
+fatal(Cannot have two CPUs with the same id (%d)\n, id);
threadContexts[id] = tc;
_numContexts++;
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: SCons: Fix how we get Mercurial revision inform...
changeset b88edb9f in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=b88edb9f description: SCons: Fix how we get Mercurial revision information since internals keep changing. diffstat: 2 files changed, 8 insertions(+), 22 deletions(-) src/SConscript| 24 ++-- src/python/m5/main.py |6 ++ diffs (75 lines): diff -r 9f7efe90084e -r b88edb9f src/SConscript --- a/src/SConscriptFri Jan 30 20:04:17 2009 -0500 +++ b/src/SConscriptFri Jan 30 20:04:57 2009 -0500 @@ -355,25 +355,16 @@ scons_dir = str(SCons.Node.FS.default_fs.SConstruct_dir) -hg_info = (Unknown, Unknown, Unknown) +hg_info = Unknown hg_demandimport = False try: if not exists(scons_dir) or not isdir(scons_dir) or \ not exists(joinpath(scons_dir, .hg)): raise ValueError(.hg directory not found) - -import mercurial.demandimport, mercurial.hg, mercurial.ui -import mercurial.util, mercurial.node -hg_demandimport = True - -repo = mercurial.hg.repository(mercurial.ui.ui(), scons_dir) -rev = mercurial.node.nullrev + repo.changelog.count() -changenode = repo.changelog.node(rev) -changes = repo.changelog.read(changenode) -id = mercurial.node.hex(changenode) -date = mercurial.util.datestr(changes[2]) - -hg_info = (rev, id, date) +import subprocess +output = subprocess.Popen(hg id -n -i -t -b.split(), + stdout=subprocess.PIPE).communicate()[0] +hg_info = output.strip() except ImportError, e: print Mercurial not found except ValueError, e: @@ -381,16 +372,13 @@ except Exception, e: print Other mercurial exception: %s % e -if hg_demandimport: -mercurial.demandimport.disable() - # Generate Python file containing a dict specifying the current # build_env flags. def makeDefinesPyFile(target, source, env): f = file(str(target[0]), 'w') build_env, hg_info = [ x.get_contents() for x in source ] print f, buildEnv = %s % build_env -print f, hgRev, hgId, hgDate = %s % hg_info +print f, hgRev = '%s' % hg_info f.close() defines_info = [ Value(build_env), Value(hg_info) ] diff -r 9f7efe90084e -r b88edb9f src/python/m5/main.py --- a/src/python/m5/main.py Fri Jan 30 20:04:17 2009 -0500 +++ b/src/python/m5/main.py Fri Jan 30 20:04:57 2009 -0500 @@ -192,8 +192,7 @@ print 'Build information:' print print 'compiled %s' % defines.compileDate; -print revision %s:%s % (defines.hgRev, defines.hgId) -print commit date %s % defines.hgDate +print revision %s % defines.hgRev print 'build options:' keys = defines.buildEnv.keys() keys.sort() @@ -268,8 +267,7 @@ print print M5 compiled %s % defines.compileDate; -print M5 revision %s:%s % (defines.hgRev, defines.hgId) -print M5 commit date %s % defines.hgDate +print M5 revision %s % defines.hgRev print M5 started %s % datetime.datetime.now().strftime(%b %e %Y %X) print M5 executing on %s % socket.gethostname() ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Notification from M5 Bugs
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#315 - Python doesn't panic when parameter with no default isn't set User who did this: - Ali Saidi (saidi) Reason for closing: - Fixed Additional comments about closing: - in rev 2831ae658bfc More information can be found at the following URL: http://www.m5sim.org/flyspray/task/315 You are receiving this message because you have requested it from the Flyspray bugtracking system. You can be removed from future notifications by visiting the URL shown above. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
