Hey all, First off, thanks for the help.
You mentioned that SUSE 8.1 uses as its default the version of binutils that was used for Flexus. Is this implying that SUSE 8.1 was the OS that Flexus was originally built using and hence should be able to compile everything with no problems? I actually installed Linux (version 10 of SUSE) specifically for this project so I really don't have a problem starting from scratch if it means that I'll get it working - if another distro or another version will work better, I'm ok with that too. I tried upgrading to the newer binutils and that didn't help either. I had originally tried using GCC 4 and that gave me errors at an earlier part of the compilation process, which were fixed after I installed 3.4.4. I also tried the "-no-whole-archive" fix to BOOST_LIBRARIES and that didn't change anything either. Thanks again for everyone's help. ~James Larson On 3/24/06, Thomas Wenisch <[email protected]> wrote: > > Hi James, > > On Fri, 24 Mar 2006, James Larson wrote: > > > Ok, thank you very much for your help. Here is my full output > > > > Building CMPFlex for v9_iface_gcc simics > > Checking dependant component v9_iface_gcc Common > > Checking dependant component v9_iface_gcc BPWarm > > <snip> > > > `.gnu.linkonce.t._ZNK5boost7archive17archive_exception4whatEv' > referenced in > > section `.rodata' of > > /home/jimmyml/flexus_2.0/components/CmpCache/CmpCache.v9.iface.gcc.a( > > CmpCacheImpl.v9_iface_gcc_o): defined in discarded section > > <snip> > > > ld returned 1 exit status > > make[6]: *** [libflexus_CMPFlex_v9_iface_gcc.so] Error 1 > > make[5]: *** [simics-v9] Error 2 > > make[4]: *** [CMPFlex] Error 2 > > make[3]: *** [CMPFlex] Error 2 > > make[2]: *** [CMPFlex] Error 2 > > make[1]: *** [CMPFlex] Error 2 > > make: *** [CMPFlex] Error 2 > > > > > > My make version is 3.80, so that shouldn't be a problem, and it's > compiling > > with GCC 3.4.4. I've had to install several different versions of GCC > to > > try to get it working, but the one that is pointed to is the 3.4.4version. > > I am using SUSE, so I'm not sure if the distro would have any effect on > this > > problem (I'm fairly new to Linux, thus explaining a lot of my problems) > > > > The root cause of this issue is apparently a bug in GCC 3.4.x that is > exposed by the linker in recent versions of binutils. Apparently gcc > emits some instructions to the linker that are incorrect, but were > harmless for versions of binutils prior to 2.15.90.0.3. > > Here are the relevant bug reports for gcc: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16276 > > There are also bug reports for binutils that may be related: > http://www.sourceware.org/bugzilla/show_bug.cgi?id=2342 > > Based on looking over various mailing list traffic about these bugs, I > believe there are 3 possible ways you can work around these problems: > > 1) Downgrade to the 2.15.90.0.3 version of binutils, or any earlier > release (we use 2.12.90.0.15, which was the default in SuSE 8.1 > ). This > fix is a pain, but is guaranteed to work. You will have to hunt > around > the documentation on SuSE's site to figure out how to install a > different version of binutils. You can figure out which version is > currently installed with "rpm -q binutils" > > 2) Try to build Flexus with gcc 4.0.x. The GCC bugs above were fixed in > 4.0.0. However, we have not tested Flexus with GCC 4. GCC 4 is still > a bit flaky and slower than GCC 3.x, so we have steered clear of it > here. It is likely that this will work without error, but you may run > into compilation problems. If you do run into errors, post them to > the > list; we may be able to help you fix them. > > 3) Try upgrading to the very latest binutils, 2.16.91.0.7, released on > 3/17/2006. That release fixes PR 2342. I can't tell for sure that > this will solve your problems, but it might. Upgrading binutils may > be > easier than downgrading it. > > > Hope that helps. > > Best Regards, > -Tom Wenisch > Computer Architecture Lab > Carnegie Mellon University > > > _______________________________________________ > SimFlex mailing list > [email protected] > https://sos.ece.cmu.edu/mailman/listinfo/simflex > SimFlex web page: http://www.ece.cmu.edu/~simflex > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://sos.ece.cmu.edu/pipermail/simflex/attachments/20060325/88c88d56/attachment.html From twenisch at ece.cmu.edu Tue Mar 28 13:29:35 2006 From: twenisch at ece.cmu.edu (Thomas Wenisch) List-Post: [email protected] Date: Tue Mar 28 13:29:52 2006 Subject: [Simflex] Flexus simulator compiling In-Reply-To: <[email protected]> References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> Message-ID: <[email protected]> Hi James, On Sat, 25 Mar 2006, James Larson wrote: > Hey all, > > First off, thanks for the help. > > You mentioned that SUSE 8.1 uses as its default the version of binutils that > was used for Flexus. Is this implying that SUSE 8.1 was the OS that Flexus > was originally built using and hence should be able to compile everything > with no problems? I actually installed Linux (version 10 of SUSE) > specifically for this project so I really don't have a problem starting from > scratch if it means that I'll get it working - if another distro or another > version will work better, I'm ok with that too. Yes, our compute cluster here runs SUSE 8.1, and all our testing is done on SUSE 8.1. If it is easy for you to use SUSE 8.1 instead of SUSE 10, I highly recommend doing that. Regards, -Tom Wenisch From twenisch at ece.cmu.edu Tue Mar 28 13:47:39 2006 From: twenisch at ece.cmu.edu (Thomas Wenisch) List-Post: [email protected] Date: Tue Mar 28 13:47:47 2006 Subject: [Simflex] Re: A question regarding to SPLASH2 In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> Hi Lu, On Sun, 26 Mar 2006, lu peng wrote: > > Hi, Tom, > <snip> > A question: how long did you take to ran an ocean with 514*514 size to > complete, if runing with > Simflex? I tried it. Seems it will take one month to finish on a Pentium 3.0G > machine with 4GB Memory. In our experience, Flexus in OoO mode runs at about 2 kIPS (maybe up to 4 or 6 kIPS depending on the IPC of your workload). You can run an app in Simics (without Flexus) to see how many instructions it is to calculate roughly how long it will take (Simics runs at 10 MIPS or faster). We don't run any applications in OoO mode from beginning to end. We usually use simulation sampling to get reasonable turnaround time - take a look at the SimFlex tutorial slides to get an idea of what we do (we are giving this tutorial again at ISCA). For scientific applications, we either sample, or run just a single iteration in OoO mode. We use TraceFlex to rapidly create a checkpoints with warm cache and branch predictor state at the start of the measurement (TraceFlex is not timing accurate, but maintains caches and branch predictors. It runs at about 1-1.5 MIPS). You can use the MagicBreak component and the sim_print.h to add annotations to your SPLASH apps to indicate iteration boundaries to the simulator. Regards, -Tom Wenisch Computer Architecture Lab Carnegie Mellon University From penglu01 at hotmail.com Tue Mar 28 14:59:32 2006 From: penglu01 at hotmail.com (lu peng) List-Post: [email protected] Date: Tue Mar 28 14:59:44 2006 Subject: [Simflex] Re: A question regarding to SPLASH2 In-Reply-To: <[email protected]> Message-ID: <[email protected]> An HTML attachment was scrubbed... URL: http://sos.ece.cmu.edu/pipermail/simflex/attachments/20060328/5141130d/attachment.html From twenisch at ece.cmu.edu Tue Mar 28 15:39:19 2006 From: twenisch at ece.cmu.edu (Thomas Wenisch) List-Post: [email protected] Date: Tue Mar 28 15:39:30 2006 Subject: [Simflex] Re: A question regarding to SPLASH2 In-Reply-To: <[email protected]> References: <[email protected]> Message-ID: <[email protected]> On Tue, 28 Mar 2006, lu peng wrote: > > Thanks for your message. I am runing an unmodified inorder model with two > workloads: specjbb and ocean. I found that it excutes instructions in > supervisor mode > which are supposed to be OS code in most of the time. I printed the info by > "cpuX.print-statistics", etc. E.g, the "ocean" workload running with an > inorder model > reported that cpu0 executed less than 2000 user insts after several days. > Other cpus also reported a few user insts executed while insts in supervisor > mode > increased a lot. So I wonder if anything wrong here? In SpecJBB, it is possible that there are a lot of OS instructions. However, in ocean, there is definately something wrong - all CPUs should be busy running user code. Your results suggest that you may actually be simulating the OS idle loop. Are you starting the in-order simulation at the start of the application? I recommend you take a Simics checkpoint in the middle of execution (e.g., at the start of the second iteration in ocean) and start your measurements from there. Second, you may want to try modifying the freq_mhz setting of each CPU in your checkpoint (you can do this by manually editing the Simics checkpoints with a text editor). Lowering this frequency (e.g. to 75MHz) will reduce the distance between timer interrupts, which will make Solaris get around to scheduling your apps sooner (on the other hand, it also increases the frequency of timer interrupts, which slow ocean down slightly). I again suggest that you put Simics magic breakpoints in your ocean code. That way, you can be absolutely certain that you are actually simulating ocean and not some other random process on the simulated machine. Once you solve the problem for ocean, hopefully the same solution will work for JBB. Regards, -Tom Wenisch Computer Architecture Lab Carnegie Mellon University
