I've reproduced the problem myself, and, having forgot exactly what you said in your email, came to the same conclusion on my own. Looking at the documentation for bitset here:
http://www.sgi.com/tech/stl/bitset.html there are two important bits. First, the |= operator takes a bitset as its parameter, not an integer. "bitset& operator|=(const bitset&)" Second, the constructor that would implicitly be used to turn an integer into a bitset has this signature: bitset(unsigned long val) and this description: "Conversion from unsigned long. Constructs a bitset, initializing the first min(N, sizeof(unsigned long) * CHAR_BIT) bits to the corresponding bits in val and all other bits, if any, to zero." So I think that pretty much says that the "intended" behavior here is to silently truncate the value when setting those flags. That certainly doesn't seem like a very useful thing to do in that case, but at least we know what the problem is. I think a simple loop that turns the integer into a bitset correctly will take care of things. The compiler will (ok, should) optimize away a loop with a small fixed iteration count, and if an unsigned long isn't big enough to hold the value, the compiler would probably have to generate code to do things in multiple steps anyway since the registers/operand sizes won't be big enough to do things in one shot. Gabe On 09/02/11 13:47, Gabe Black wrote: > Hmm, that might be trickier to fix than I was hoping for, although still > important to fix. I'm (slowly) in the process of getting a VM set up > with a 32 bit installation in it so I can do some testing. > > Gabe > > On 09/02/11 07:27, Tim Harris (RESEARCH) wrote: >> Hi, >> >> I spent a bit of time tracking down a problem like this on 32-bit Cygwin -- >> I mentioned this on the list a while back, but I'm not sure what the >> conclusion was about where to fix this (e.g., if it was a Cygwin bug or a >> gem5 bug -- I worked around it by switching to Linux in a VM, still all >> 32-bit). >> >> Here are the details: >> >> It looked like some updates to the flags field defined on StaticInstBase >> were being truncated. I was seeing IsLastMicroop being lost, leading to >> assert-fails (m5.opt) / crashes (m5.fast). >> >> decoder.cc was generating uint64_t initializers for the flags and these were >> being passed intact to the X86MicroopBase constructor in microop.hh. The >> constructor then initialized the flags bitset by using: >> >> flags |= setFlags; >> >> (where flags is a std::bitset, and setFlags is a uint64_t). >> >> I think the implementation of std::bitset I had with Cygwin was only taking >> the bottom 32-bits, rather than splitting a uint64_t over two 32-bit words. >> >> I meant to look into this further, and see whether this was a bug in >> std::bitset, or in M5's use of it... but I was travelling, switched to using >> Virtual PC, and unfortunately forgot to get back to the problem. >> >> --Tim >> >> >> >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Gabe Black >> Sent: 02 September 2011 14:35 >> To: gem5 users mailing list >> Subject: Re: [gem5-users] Invalid microop >> >> I would rather fix bugs than document them. It's probably something >> silly since we rarely run on 32 bit machines. >> >> Gabe >> >> On 09/01/11 23:25, Mahmood Naderan wrote: >>> I suggest adding an entry in FAQ about this problem. >>> If you run X86_FS on a 32 bit host, you will get "panic: Invalid microop!" >>> >>> On 9/1/11, [email protected] <[email protected]> wrote: >>>> Hi Gabe! >>>> >>>> The problem was occurring on Ubuntu 11.4 32-bit version. Now I installed >>>> Ubuntu 11.4 64-bit version with the same setup and it works! The setup is >>>> the following: >>>> >>>> scons 2.0.1 >>>> swig 1.3.40 >>>> gcc 4.5.2 >>>> python 2.7 >>>> >>>> So the only difference was OS (32-bit not working and now with 64-bit >>>> working). The machine is Pentium Dual Core E5400. Hope this helps! >>>> >>>> Kind regards, >>>> Borislav Nikolic >>>> >>>> On Thu, 01 Sep 2011 04:43:58 -0700, Gabe Black <[email protected]> >>>> wrote: >>>>> A number of people have had problems like this, so if we can figure out >>>>> what's going on that would be great. The basic problem is that one of >>>>> the very first microops, maybe the first or only one or two later, is >>>>> not valid for some reason. Please describe your setup, including >>>>> versions of your compiler, etc, if you're on a 32 bit machine, the >>>>> version of gem5, where you got your kernel, etc. If you can, try this >>>>> again on a different computer with a different setup and see if it works >>>>> there. Also run with --debug-flags=Exec,ExecMacro and see what it's >>>>> trying to execute. gdb might help too. >>>>> >>>>> Gabe >>>>> >>>>> On 09/01/11 00:03, Mahmood Naderan wrote: >>>>>> Are you using 32 bit host? >>>>>> >>>>>> On 8/31/11, [email protected] <[email protected]> wrote: >>>>>>> Dear GEM5 users, >>>>>>> >>>>>>> I was able to build ALPHA_FS architecture and boot >>>>>>> linux on it. However, when I tried to do the same with X86_FS (after >>>>>>> downloading x86 binaries), I got the following error: >>>>>>> >>>>>>> >>>>>>> borni@borni-G31M-ES2L:~/gem5$ ./build/X86_FS/m5.opt --verbose >>>>>>> configs/example/fs.py >>>>>>> --kernel=/home/borni/Desktop/X86_GEM5/binaries/x86_64-vmlinux-2.6.22.9 >>>>>>> gem5 >>>>>>> Simulator System. http://gem5.org >>>>>>> gem5 is copyrighted software; use the >>>>>>> --copyright option for details. >>>>>>> >>>>>>> gem5 compiled Aug 29 2011 13:01:34 >>>>>>> gem5 >>>>>>> started Aug 31 2011 18:01:01 >>>>>>> gem5 executing on borni-G31M-ES2L >>>>>>> command >>>>>>> line: ./build/X86_FS/m5.opt --verbose configs/example/fs.py >>>>>>> --kernel=/home/borni/Desktop/X86_GEM5/binaries/x86_64-vmlinux-2.6.22.9 >>>>>>> warning: >>>>>>> add_child('terminal'): child 'terminal' already has parent >>>>>>> Global frequency >>>>>>> set at 1000000000000 ticks per second >>>>>>> info: kernel located at: >>>>>>> /home/borni/Desktop/X86_GEM5/binaries/x86_64-vmlinux-2.6.22.9 >>>>>>> 0: rtc: >>>>>>> Real-time clock set to Sun Jan 1 00:00:00 2012 >>>>>>> Listening for com_1 >>>>>>> connection on port 3456 >>>>>>> warn: Reading current count from inactive timer. >>>>>>> 0: >>>>>>> system.remote_gdb.listener: listening for remote gdb #0 on port 7000 >>>>>>> **** >>>>>>> REAL SIMULATION **** >>>>>>> info: Entering event queue @ 0. Starting >>>>>>> simulation... >>>>>>> panic: Invalid microop! >>>>>>> @ cycle >>>>>>> 1000 >>>>>>> [invoke:build/X86_FS/arch/generic/debugfaults.hh, line 93] >>>>>>> Memory >>>>>>> Usage: 232296 KBytes >>>>>>> Program aborted at cycle 1000 >>>>>>> Aborted >>>>>>> >>>>>>> I found two >>>>>>> similar questions raised on this list couple of months ago, but nobody >>>>>>> replied. I tied with builds ".opt", ".fast", ".debug" with both GEM5 >>>>>>> stable >>>>>>> and development versions. Always the same result. Am I doing something >>>>>>> wrong? >>>>>>> >>>>>>> Kind regards, >>>>>>> >>>>>>> Borislav Nikolic >>>>>> _______________________________________________ >>>>>> gem5-users mailing list >>>>>> [email protected] >>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>>> _______________________________________________ >>>>> gem5-users mailing list >>>>> [email protected] >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> _______________________________________________ >>>> gem5-users mailing list >>>> [email protected] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>> _______________________________________________ >>> gem5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
