Re: [gem5-users] SPECCPU 2006 application crashes on x86 gem5
Thanks a lot for the inputs, Gururaj and Gabe. Thanks, Shyam On Mon, Jul 1, 2019 at 1:21 AM Saileshwar, Gururaj wrote: > Hi Shyam, > > I also faced this issue with “movntdq_Mo_Vo” in the recent past when I > was trying to compile and run SPEC2006 with Gem5. > > I managed to debug it to some extent – the source of these unimplemented > instructions is likely one of the linked libraries (mostly glibc) that the > binary uses. > > While I didn’t manage to find a fix, I got a work-around: I compiled my > binaries with static linking (-static flag to linker) on a older system > that apparently did not use this instruction. Subsequently, those binaries > also worked with Gem5 on my newer system where I was originally facing this > issue. Sorry, I am unable to give you precise versions of the SW I used – I > no longer have access. > > Hope this helps! > Gururaj > > From: gem5-users on behalf of Gabe Black < > gabebl...@google.com> > Reply-To: gem5 users mailing list > Date: Sunday, June 30, 2019 at 10:42 PM > To: Shyam Murthy > Cc: gem5 users mailing list > Subject: Re: [gem5-users] SPECCPU 2006 application crashes on x86 gem5 > > Hi Shyam. Part of the issue is an unfortunate aspect of how gcc works > where there are some components that are built when gcc itself is > built/installed which use certain settings, and if you link against them > later (which gcc will do implicitly/automatically in at least a couple > cases) those settings won't change and you can get, for instance, > instructions that you'd turned off. There can be even bigger issues if you > change flags that break ABI compatibility since those libraries won't work > at all instead of just disregarding your settings. > > There are apparently also header files which get pulled in which use > features you can technically disable, but disabling them breaks those > headers. > > I think the linked thread is probably where someone was using instructions > which were too new to be supported, but in your case I think (without > having the time to check for sure) that that instruction isn't supported > because it's the non-temporal version, and there isn't (or at least wasn't) > a good way to implement that behavior. I vaguely remember adding a flag > which disabled caching which you might find if you look at the repository > history or archived emails, so it may be possible to implement that > instruction properly now. > > Gabe > > On Sun, Jun 30, 2019 at 4:38 PM Shyam Murthy > wrote: > >> Hi, >> >> Additionally, I also tried using the -mno-sse2 flag, with which it >> compiles, but the error persists. However, when I tried to compile using >> the -mno-sse flag, then compilation fails saying: >> >> */usr/include/x86_64-linux-gnu/bits/stdlib-float.h: In function 'atof': >> /usr/include/x86_64-linux-gnu/bits/stdlib-float.h:26:1: error: SSE register >> return with SSE disabled* >> >> Thanks, >> Shyam >> >> On Sun, Jun 30, 2019 at 3:24 PM Shyam Murthy >> wrote: >> >>> Hi, >>> >>> This is slightly different, there is no panic message here. However, >>> this instruction is unimplemented, but is required by the application for >>> its execution, causing it to abort. As in your link, Gabe mentions that we >>> need to tell the compiler not to use this instruction. I was unsure how to >>> achieve the same, I tried passing the -msse flag to gcc during compilation, >>> but the movntdq instruction still seems to be getting generated. >>> >>> Thanks, >>> Shyam >>> >>> On Sun, Jun 30, 2019 at 1:06 PM Kleovoulos Kalaitzidis < >>> kleovoulos.kalaitzi...@inria.fr> wrote: >>> Hello, it is normal to get these warnings for unimplemented instructions. However, in my experience, these warnings are not the case for aborting. Normally some panic message follows, but maybe not related to this "warn". For instance, there is the case of avx instructions that are not implemented and will abort the execution : https://gem5-users.gem5.narkive.com/jO22f7kV/spec2017-on-gem5-se-mode Regards, -- Kleovoulos Kalaitzidis Doctorant - Équipe PACAP Centre de recherche INRIA Rennes - Bretagne Atlantique Bâtiment 12E, Bureau E321, Campus de Beaulieu, 35042 Rennes Cedex, France -- *From: *"Shyam Murthy" *To: *"gem5 users mailing list" *Sent: *Sunday, June 30, 2019 7:02:37 PM *Subject: *[gem5-users] SPECCPU 2006 application crashes on x86 gem5 Hi All, I am trying to run some of the FP applications from SPECCPU 2006. However, for some of these applications (like povray, tonto), I get an error that says: warn: instruction 'movntdq_Mo_Vo' unimplemented. I am compiling these applications on my machine, and then running them on x86 gem5. My machine uses gcc version 7.4.0. I tried using gcc version 5.5 (already installed on my machine), but the problem persists. Any suggestions as to
Re: [gem5-users] gem5 X86 Full System fails with DerivO3CPU
Hello Everyone, Yaz: I do not change anything, I am using commit 2a98a994df296f818b05da90ba073d879562da04 of gem5. Is there anyone who was able to *boot* the full system for x86 ISA using O3CPU? My command line : *build/X86/gem5.opt configs/example/fs.py --kernel=x86_64-vmlinux-2.6.22.9 --disk-image=linux-x86.img --cpu-type=DerivO3CPU --caches* Best regards, Abhishek On Fri, Mar 8, 2019 at 2:09 PM Ayaz Akram wrote: > Hi Abhishek, > > I wonder if you are using the default CPU configuration for full-system or > do you have any changes? > > Regards > -Ayaz > > On Wed, Mar 6, 2019 at 2:20 PM Abhishek Singh < > abhishek.singh199...@gmail.com> wrote: > >> Hello Everyone, >> >> I am trying to run the gem5 full system with X86 ISA and DerivO3CPU >> >> I have built image and kernel following Jason's Website (ref: >> http://www.lowepower.com/jason/setting-up-gem5-full-system.html) >> My image is* Ubuntu 16.04.5 LTS* >> My kernel is *Linux-4.8.13* >> Gem5 version: Latest as of 6th March 2019 >> >> The image and kernel work fine with Atomic and Timing CPU for x86. >> But for O3CPU, it gives an error as shown below: >> " >> >> command line: *./build/X86/gem5.opt configs/example/fs.py >> --script=./script.rcS >> --disk-image=/home/abs218/image_kernel/ubuntu-test.img >> --kernel=/home/abs218/new_fs/gem5/linux-4.8.13/vmlinux --caches --l2cache >> --cpu-type=DerivO3CPU* >> >> >> Global frequency set at 1 ticks per second >> >> warn: DRAM device capacity (8192 Mbytes) does not match the address range >> assigned (512 Mbytes) >> >> info: kernel located at: /home/abs218/new_fs/gem5/linux-4.8.13/vmlinux >> >> system.pc.com_1.device: Listening for connections on port 3456 >> >> 0: rtc: Real-time clock set to Sun Jan 1 00:00:00 2012 >> >> 0: system.remote_gdb: listening for remote gdb on port 7000 >> >> warn: Reading current count from inactive timer. >> >> REAL SIMULATION >> >> info: Entering event queue @ 0. Starting simulation... >> >> *gem5.opt: build/X86/mem/packet.hh:1047: T* Packet::getPtr() [with T = >> unsigned char]: Assertion `flags.isSet(STATIC_DATA|DYNAMIC_DATA)' failed* >> . >> >> Program aborted at tick 11637500 >> >> --- BEGIN LIBC BACKTRACE --- >> >> ./build/X86/gem5.opt(_Z15print_backtracev+0x2c)[0x561f4b44d8bc] >> >> ./build/X86/gem5.opt(_Z12abortHandleri+0x4a)[0x561f4b45fc8a] >> >> /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f25466db890] >> >> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f2544e02e97] >> >> /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f2544e04801] >> >> /lib/x86_64-linux-gnu/libc.so.6(+0x3039a)[0x7f2544df439a] >> >> /lib/x86_64-linux-gnu/libc.so.6(+0x30412)[0x7f2544df4412] >> >> >> ./build/X86/gem5.opt(_ZN6X86ISA13handleIprReadEP13ThreadContextP6Packet+0x17c)[0x561f4ace817c] >> >> >> ./build/X86/gem5.opt(_ZN7LSQUnitI9O3CPUImplE4readEPN3LSQIS0_E10LSQRequestEi+0x431)[0x561f4aca8781] >> >> >> ./build/X86/gem5.opt(_ZN3LSQI9O3CPUImplE4readEPNS1_10LSQRequestEi+0xad)[0x561f4acee75d] >> >> >> ./build/X86/gem5.opt(_ZN3LSQI9O3CPUImplE11pushRequestERK14RefCountingPtrI13BaseO3DynInstIS0_EEbPhjm5FlagsImEPmP15AtomicOpFunctor+0x523)[0x561f4aceecf3] >> >> >> ./build/X86/gem5.opt(_ZN11BaseDynInstI9O3CPUImplE15initiateMemReadEmj5FlagsImE+0x7b)[0x561f4ac8cb3b] >> >> >> ./build/X86/gem5.opt(_ZNK10X86ISAInst5LdBig11initiateAccEP11ExecContextPN5Trace10InstRecordE+0xd1)[0x561f4b99e521] >> >> >> ./build/X86/gem5.opt(_ZN13BaseO3DynInstI9O3CPUImplE11initiateAccEv+0x45)[0x561f4acbfc15] >> >> >> ./build/X86/gem5.opt(_ZN7LSQUnitI9O3CPUImplE11executeLoadERK14RefCountingPtrI13BaseO3DynInstIS0_EE+0x57)[0x561f4acf87e7] >> >> >> ./build/X86/gem5.opt(_ZN3LSQI9O3CPUImplE11executeLoadERK14RefCountingPtrI13BaseO3DynInstIS0_EE+0x3b)[0x561f4ace8a0b] >> >> >> ./build/X86/gem5.opt(_ZN10DefaultIEWI9O3CPUImplE12executeInstsEv+0xf06)[0x561f4acd6e96] >> >> >> ./build/X86/gem5.opt(_ZN10DefaultIEWI9O3CPUImplE4tickEv+0x8c0)[0x561f4acda9a0] >> >> >> ./build/X86/gem5.opt(_ZN9FullO3CPUI9O3CPUImplE4tickEv+0x144)[0x561f4acac574] >> >> ./build/X86/gem5.opt(_ZN10EventQueue10serviceOneEv+0xd9)[0x561f4b455699] >> >> ./build/X86/gem5.opt(_Z9doSimLoopP10EventQueue+0x87)[0x561f4b470e77] >> >> ./build/X86/gem5.opt(_Z8simulatem+0xcaa)[0x561f4b471eba] >> >> ./build/X86/gem5.opt(+0x5b4d4e)[0x561f4aaedd4e] >> >> ./build/X86/gem5.opt(+0x591bf4)[0x561f4aacabf4] >> >> >> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x64d7)[0x7f2546995697] >> >> >> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f2546ac7278] >> >> >> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5bf6)[0x7f2546994db6] >> >> >> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f2546ac7278] >> >> >> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5bf6)[0x7f2546994db6] >> >> >> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7d8)[0x7f2546ac7278] >> >> >> /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0(PyEval_Eval
