gem5 / gem5

The official repository for the gem5 computer-system architecture simulator.

The gem5 Simulator

This is the repository for the gem5 simulator. It contains the full source code for the simulator and all tests and regressions.

The gem5 simulator is a modular platform for computer-system architecture research, encompassing system-level architecture as well as processor microarchitecture. It is primarily used to evaluate new hardware designs, system software changes, and compile-time and run-time system optimizations.

The main website can be found at http://www.gem5.org.

Testing status

Note: These regard tests run on the develop branch of gem5: https://github.com/gem5/gem5/tree/develop.

Getting started

A good starting point is http://www.gem5.org/about, and for more information about building the simulator and getting started please see http://www.gem5.org/documentation and http://www.gem5.org/documentation/learning_gem5/introduction.

Building gem5

To build gem5, you will need the following software: g++ or clang, Python (gem5 links in the Python interpreter), SCons, zlib, m4, and lastly protobuf if you want trace capture and playback support. Please see http://www.gem5.org/documentation/general_docs/building for more details concerning the minimum versions of these tools.

Once you have all dependencies resolved, execute scons build/ALL/gem5.opt to build an optimized version of the gem5 binary (gem5.opt) containing all gem5 ISAs. If you only wish to compile gem5 to include a single ISA, you can replace ALL with the name of the ISA. Valid options include ARM, NULL, MIPS, POWER, RISCV, SPARC, and X86 The complete list of options can be found in the build_opts directory.

See https://www.gem5.org/documentation/general_docs/building for more information on building gem5.

The Source Tree

The main source tree includes these subdirectories:

• build_opts: pre-made default configurations for gem5
• build_tools: tools used internally by gem5's build process.
• configs: example simulation configuration scripts
• ext: less-common external packages needed to build gem5
• include: include files for use in other programs
• site_scons: modular components of the build system
• src: source code of the gem5 simulator. The C++ source, Python wrappers, and Python standard library are found in this directory.
• system: source for some optional system software for simulated systems
• tests: regression tests
• util: useful utility programs and files

gem5 Resources

To run full-system simulations, you may need compiled system firmware, kernel binaries and one or more disk images, depending on gem5's configuration and what type of workload you're trying to run. Many of these resources can be obtained from https://resources.gem5.org.

More information on gem5 Resources can be found at https://www.gem5.org/documentation/general_docs/gem5_resources/.

Getting Help, Reporting bugs, and Requesting Features

We provide a variety of channels for users and developers to get help, report bugs, requests features, or engage in community discussions. Below are a few of the most common we recommend using.

• GitHub Discussions: A GitHub Discussions page. This can be used to start discussions or ask questions. Available at https://github.com/orgs/gem5/discussions.
• GitHub Issues: A GitHub Issues page for reporting bugs or requesting features. Available at https://github.com/gem5/gem5/issues.
• Jira Issue Tracker: A Jira Issue Tracker for reporting bugs or requesting features. Available at https://gem5.atlassian.net/.
• Slack: A Slack server with a variety of channels for the gem5 community to engage in a variety of discussions. Please visit https://www.gem5.org/join-slack to join.
• [email protected]: A mailing list for users of gem5 to ask questions or start discussions. To join the mailing list please visit https://www.gem5.org/mailing_lists.
• [email protected]: A mailing list for developers of gem5 to ask questions or start discussions. To join the mailing list please visit https://www.gem5.org/mailing_lists.

Contributing to gem5

We hope you enjoy using gem5. When appropriate we advise charing your contributions to the project. https://www.gem5.org/contributing can help you get started. Additional information can be found in the CONTRIBUTING.md file.

gem5's Issues

"util/cpt_upgrader.py" not updating RISC-V checkpoints from v23.0.0.1 to changes in #83

To reproduce:

# Obtain the gem5 repo
git clone https://github.com/gem5/gem5.git
cd gem5

# Obtain the #83 PR
git fetch origin pull/83/head:rvv
git switch rvv

wget http://dist.gem5.org/dist/develop/checkpoints/riscv-hello-example-checkpoint-20230222.tar
mkdir checkpoint
tar xf riscv-hello-example-checkpoint-20230222.tar -C checkpoint/
./util/cpt_upgrader.py -v checkpoint

The following output is returned:

Processing file checkpoint/m5.cpt.... 

has tags arm-miscreg-teehbr arm-ccregs arm-gem5-gic-ext dvfs-perflevel x86-add-tlb ide-dma-abort remove-arm-cpsr-mode-miscreg etherswitch armv8 register-files ruby-block-size-bytes mempool-to-seworkload process-fdmap-rename cpu-pid globals-to-root smt-interrupts memory-per-range mempool-sections isa-is-simobject arm-sysreg-mapping-ns arm-contextidr-el2 multiple-event-queues arm-hdlcd-upgrade arm-sve arm-gicv2-banked-regs 

...nothing to do 

I have only proven this fault when working with #83 for updating a checkpoint from v23.0.0.1 to that necessary for the PR. The limitation of "util/cpt_upgrader.py" may exist elsewhere.

can gem5 run deepbench that baidu released

How to enable network in the X86 full system simulation

Is this function supported? Or how can I accomplish this?
Someone has given me a patch manual (which can be found X86 networking(1).pdf
) to follow, but both of us don't know which version of Gem5 can apply for the patch.
Any advice? Thanks.

Remove "python/m5/info.py"

This file is automatically generated during compilation and contains a copy of the LICENSE, COPYING, and README.md, which is then compiled into the gem5 binary.

As pointed out here: #71 (comment), this is not needed and should probably be removed to avoid complexity.

Attribute Error in Full System Simulation

Hi,

I am trying to run a x86 Full System Simulation on Ubuntu 16.04 that is hosted on a X86_64 machine, however with any configuration file, even the example fs.py, I see the following error:

**command line: build/X86/gem5.opt configs/example/fs.py

Global frequency set at 1000000000000 ticks per second
Error in unproxying param 'device' of system.pc.com_1
Traceback (most recent call last):
File "", line 1, in
File "/apps/gem5/src/python/m5/main.py", line 433, in main
exec filecode in scope
File "configs/example/fs.py", line 372, in
Simulation.run(options, root, test_sys, FutureClass)
File "/apps/gem5/configs/common/Simulation.py", line 589, in run
m5.instantiate(checkpoint_dir)
File "/apps/gem5/src/python/m5/simulate.py", line 90, in instantiate
for obj in root.descendants(): obj.unproxyParams()
File "/apps/gem5/src/python/m5/SimObject.py", line 1332, in unproxyParams
value = value.unproxy(self)
File "/apps/gem5/src/python/m5/proxy.py", line 101, in unproxy
(self.path(), self._pdesc.ptype_str, base.path())
AttributeError: Can't resolve proxy 'any' of type 'SerialDevice' from 'system.pc.com_1'**

I am using the latest gem5 from github and following the steps listed here for setup:
http://gem5.org/Running_gem5
http://learning.gem5.org/book/part4/intro.html
Could you help with resolving this issue?

Thanks,

Majid

option --cpu-type invalid choice: 'inorder'

Hi,
I have a problem setting cup-type to 'inorder'. The command line:
./build/X86/gem5.opt ./configs/example/fs.py --script=./scripts/x264/x264_64c_simsmall.rcS
-n 4 --cpu-type inorder --mem-size=2GB --caches --l2cache
The error message:
fs.py: error: option --cpu-type: invalid choice: 'inorder' (choose from 'arm_detailed', 'AtomicSimpleCPU', 'X86KvmCPU', 'DerivO3CPU', 'TimingSimpleCPU', 'timing', 'detailed', 'kvm', 'atomic')

How to run the simulator with inorder CPU? I'm a new user for Gem5.
The InOrderCpu has been implemented. Right? (src/cpu/inorder)
Thanks.

Best Regards,
Yao Liu

Can't generate compile_commands.json by using scons compilation_db

I want to generate a compilation database by using compilation_db in scons.
I add the following code to SConstruct file, but it don't work
`main.Tool('compilation_db')

main.CompilationDatabase('compile_commands.json')`

I add .Tool('compilation_db') and .CompilationDatabase('compile_commands.json') to many env objects on SConstruct and src/SConscript, it don't work too.

It's confusing to me. How to generate compilation database of gem5?
I'm using ubuntu 22.04, the scons version is 4.0.1

Default values of "apu_se.py" don't work

I've been tried to run HSAIL_X86 arch by "scons build/HSAIL_X86/gem5.opt" and running with "config/examples/apu_se.py" configuration.
I installed CLOC compiler binaries and HSA-runtime package which are mentioned in https://github.com/HSAFoundation/CLOC/blob/cf777856cfce86d11ea97c245992971159b85a4d/INSTALL.md.
And then, with compiled binary (HelloWorld) and generated GPU kernel binary (hw.asm), I tried to run APU simulation.
However, it didn't work and printed messeages as follows:

choi@choi-desktop:~/Simulator/gem5$ build/HSAIL_X86/gem5.opt configs/example/apu_se.py -c ~/Simulator/CLOC/examples/snack/helloworld/HelloWorld -k ~/Simulator/CLOC/examples/snack/helloworld/hw.asm
gem5 Simulator System. http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 compiled Dec 28 2017 13:59:23
gem5 started Dec 29 2017 15:47:08
gem5 executing on choi-desktop, pid 11084
command line: build/HSAIL_X86/gem5.opt configs/example/apu_se.py -c /home/choi/Simulator/CLOC/examples/snack/helloworld/HelloWorld -k /home/choi/Simulator/CLOC/examples/snack/helloworld/hw.asm

Global frequency set at 1000000000000 ticks per second
warn: system.ruby.network adopting orphan SimObject param 'int_links'
warn: system.ruby.network adopting orphan SimObject param 'ext_links'
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (512 Mbytes)
fatal: Number of ISAs (0) assigned to the CPU does not equal number of threads (1).
Memory Usage: 1170608 KBytes
choi@choi-desktop:~/Simulator/gem5$

I think some default values in "apu_se.py" are defined as invalid parameter, but I'm struggling to solve it.
Please give me some advices.

macOS build failure due to conflicting defines in gdbremote/signals.hh

This commit breaks building on macOS 7230a3e as EXC_* are already defined in exception_types.h. I'm happy to submit a PR undef'ing these, but I'm not certain if that is the desired fix?

"SyntaxError: Can't build lexer" on Ubuntu 23.04

I am getting the following error when trying to compile gem5 on Ubuntu 23.04 with scons 4.0.1:

ERROR:fm_proj_ply:/home/alexander/Desktop/junkyard/ramreuse/dev/gem5/build/X86/arch/arm/fastmodel/SConscript:220: Invalid regular expression for rule 't_STRLIT'. global flags not at the start of the expression at position 13 SyntaxError: Can't build lexer

I've been able to build gem5 in the gem5 Ubuntu 22.04 Docker image but I'm not sure why I'm getting this error when compiling on my own machine. Thank you for the help.

aarch64 GDB step debugging fails with "Remote 'g' packet reply is too long"

Has anyone ever made this work?

68af229, gdb 7.11.1 built by Buildroot

An extremely similar aarch64 setup works for QEMU, and x86 and arm both work for gem5, just aarch64 does not.

gem5 command:

M5_PATH='/home/ciro/bak/git/linux-kernel-module-cheat/buildroot/output.aarch64~/build/gem5-1.0/system'  '/home/ciro/bak/git/linux-kernel-module-cheat/buildroot/output.aarch64~/build/gem5-1.0/gem5/build/ARM/gem5.opt'  '/home/ciro/bak/git/linux-kernel-module-cheat/buildroot/output.aarch64~/build/gem5-1.0/gem5/configs/example/fs.py' --checkpoint-dir='./m5out/cpts/aarch64' --disk-image='/home/ciro/bak/git/linux-kernel-module-cheat/buildroot/output.aarch64~/images/rootfs.ext2' --kernel='/home/ciro/bak/git/linux-kernel-module-cheat/buildroot/output.aarch64~/build/linux-custom/vmlinux' --mem-size=256MB --num-cpus='1'  --command-line='earlyprintk=pl011,0x1c090000 console=ttyAMA0 lpj=19988480 rw loglevel=8 mem=256MB root=/dev/sda nokaslr norandmaps printk.devkmsg=on printk.time=y' --dtb-file='/home/ciro/bak/git/linux-kernel-module-cheat/buildroot/output.aarch64~/build/gem5-1.0/gem5/system/arm/dt/armv8_gem5_v1_1cpu.dtb' --machine-type=VExpress_GEM5_V1   

gdb command:

/home/ciro/bak/git/linux-kernel-module-cheat/buildroot/output.aarch64~/host/usr/bin/aarch64-linux-gdb  -q -ex 'add-auto-load-safe-path /home/ciro/bak/git/linux-kernel-module-cheat/buildroot/output.aarch64~/build/linux-custom' -ex 'file vmlinux' -ex 'target remote localhost:7000'  -ex 'continue' -ex 'lx-symbols ../kernel_module-1.0/'  

gem5 stdout says:

4107766500: system.remote_gdb: remote gdb attached
warn: Couldn't read data from debugger.
4107767500: system.remote_gdb: remote gdb detached

Error message:

Reading symbols from vmlinux...done.
Remote debugging using localhost:7000
Remote 'g' packet reply is too long: 000000000000000090a4f90fc0ffffff4875450ec0ffffff01000000000000000100000000000000000000000000000001000000000000000000000000000000ffffffffffffffff646d60616b64fffe7f7f7f7f7f7f7f7f0101010101010101300000000000000000000000ffffffff48454422207d2c2017162f21262820160100000000000000070000000000000001000000000000004075450ec0ffffffc073450ec0ffffff82080000000000004075450ec0ffffff8060f90fc0ffffffc073450ec0fffffff040900880ffffff40ab400ec0ffffff586d900880ffffff0068a20ec0ffffff903b010880ffffffc8ff210880ffffff903b010880ffffffccff210880ffffff050000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Tried to add set tdesc filename aarch64.xml as mentioned at: https://stackoverflow.com/questions/27411621/remote-g-packet-reply-is-too-long-aarch64-arm64/27430836#27430836 but no change.

This is the exact reproduction setup: https://github.com/************/linux-kernel-module-cheat/tree/a1a6a5d6fb417238ce4064ef7b3319686f02fd6b#gem5-gdb-step-debug-kernel-aarch64

Error Compiling with LLVM 6.0 on Ubuntu Artful

Hello,
I'm trying to build the X86_MOESI_AMD_Base model of gem5 using clang/llvm. I got it running las week with gcc-7 on Ubuntu artful. I have it running on RHEL 6, using clang 5.
So, trying to build it using the llvm distributed by LLVM.org, I'm gettign the following error on uBuntu Artful:

7 warnings generated.
 [     CXX] X86_MOESI_AMD_Base/mem/ruby/common/Address.cc -> .o
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:588:8: error: delete called on non-final 'Stats::ScalarStatNode' that has virtual functions but non-virtual
      destructor [-Werror,-Wdelete-non-virtual-dtor]
              delete __p;
              ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ScalarStatNode *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ScalarStatNode *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::ScalarStatNode, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3030:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::ScalarStatNode, void>' requested here
        : node(new ScalarStatNode(s.info()))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:376:9: error: delete called on non-final 'Stats::ScalarStatNode' that has virtual functions but non-virtual
      destructor [-Werror,-Wdelete-non-virtual-dtor]
      { delete _M_ptr; }
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:371:7: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::ScalarStatNode *,
      __gnu_cxx::_S_atomic>::_M_dispose' requested here
      _Sp_counted_ptr(_Ptr __p) noexcept
      ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:584:20: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::ScalarStatNode *,
      __gnu_cxx::_S_atomic>::_Sp_counted_ptr' requested here
              _M_pi = new _Sp_counted_ptr<_Ptr, _Lp>(__p);
                          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ScalarStatNode *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ScalarStatNode *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::ScalarStatNode, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3030:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::ScalarStatNode, void>' requested here
        : node(new ScalarStatNode(s.info()))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:588:8: error: delete called on non-final 'Stats::VectorStatNode' that has virtual functions but non-virtual
      destructor [-Werror,-Wdelete-non-virtual-dtor]
              delete __p;
              ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::VectorStatNode *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::VectorStatNode *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::VectorStatNode, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3054:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::VectorStatNode, void>' requested here
        : node(new VectorStatNode(s.info()))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:376:9: error: delete called on non-final 'Stats::VectorStatNode' that has virtual functions but non-virtual
      destructor [-Werror,-Wdelete-non-virtual-dtor]
      { delete _M_ptr; }
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:371:7: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::VectorStatNode *,
      __gnu_cxx::_S_atomic>::_M_dispose' requested here
      _Sp_counted_ptr(_Ptr __p) noexcept
      ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:584:20: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::VectorStatNode *,
      __gnu_cxx::_S_atomic>::_Sp_counted_ptr' requested here
              _M_pi = new _Sp_counted_ptr<_Ptr, _Lp>(__p);
                          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::VectorStatNode *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::VectorStatNode *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::VectorStatNode, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3054:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::VectorStatNode, void>' requested here
        : node(new VectorStatNode(s.info()))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:588:8: error: delete called on non-final 'Stats::FormulaNode' that has virtual functions but non-virtual destructor
      [-Werror,-Wdelete-non-virtual-dtor]
              delete __p;
              ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::FormulaNode *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::FormulaNode *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::FormulaNode, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3065:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::FormulaNode, void>' requested here
        : node(new FormulaNode(f))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:376:9: error: delete called on non-final 'Stats::FormulaNode' that has virtual functions but non-virtual destructor
      [-Werror,-Wdelete-non-virtual-dtor]
      { delete _M_ptr; }
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:371:7: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::FormulaNode *,
      __gnu_cxx::_S_atomic>::_M_dispose' requested here
      _Sp_counted_ptr(_Ptr __p) noexcept
      ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:584:20: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::FormulaNode *,
      __gnu_cxx::_S_atomic>::_Sp_counted_ptr' requested here
              _M_pi = new _Sp_counted_ptr<_Ptr, _Lp>(__p);
                          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::FormulaNode *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::FormulaNode *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::FormulaNode, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3065:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::FormulaNode, void>' requested here
        : node(new FormulaNode(f))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:588:8: error: delete called on non-final 'Stats::ConstNode<signed char>' that has virtual functions but non-virtual
      destructor [-Werror,-Wdelete-non-virtual-dtor]
              delete __p;
              ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<signed char> *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<signed char> *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::ConstNode<signed char>, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3082:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::ConstNode<signed char>, void>' requested here
        : node(new ConstNode<signed char>(value))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:376:9: error: delete called on non-final 'Stats::ConstNode<signed char>' that has virtual functions but non-virtual
      destructor [-Werror,-Wdelete-non-virtual-dtor]
      { delete _M_ptr; }
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:371:7: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::ConstNode<signed char> *,
      __gnu_cxx::_S_atomic>::_M_dispose' requested here
      _Sp_counted_ptr(_Ptr __p) noexcept
      ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:584:20: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::ConstNode<signed char> *,
      __gnu_cxx::_S_atomic>::_Sp_counted_ptr' requested here
              _M_pi = new _Sp_counted_ptr<_Ptr, _Lp>(__p);
                          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<signed char> *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<signed char> *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::ConstNode<signed char>, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3082:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::ConstNode<signed char>, void>' requested here
        : node(new ConstNode<signed char>(value))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:588:8: error: delete called on non-final 'Stats::ConstNode<unsigned char>' that has virtual functions but
      non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor]
              delete __p;
              ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<unsigned char> *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<unsigned char> *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::ConstNode<unsigned char>, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3090:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::ConstNode<unsigned char>, void>' requested here
        : node(new ConstNode<unsigned char>(value))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:376:9: error: delete called on non-final 'Stats::ConstNode<unsigned char>' that has virtual functions but
      non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor]
      { delete _M_ptr; }
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:371:7: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::ConstNode<unsigned char> *,
      __gnu_cxx::_S_atomic>::_M_dispose' requested here
      _Sp_counted_ptr(_Ptr __p) noexcept
      ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:584:20: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::ConstNode<unsigned char> *,
      __gnu_cxx::_S_atomic>::_Sp_counted_ptr' requested here
              _M_pi = new _Sp_counted_ptr<_Ptr, _Lp>(__p);
                          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<unsigned char> *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<unsigned char> *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::ConstNode<unsigned char>, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3090:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::ConstNode<unsigned char>, void>' requested here
        : node(new ConstNode<unsigned char>(value))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:588:8: error: delete called on non-final 'Stats::ConstNode<short>' that has virtual functions but non-virtual
      destructor [-Werror,-Wdelete-non-virtual-dtor]
              delete __p;
              ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<short> *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<short> *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::ConstNode<short>, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3098:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::ConstNode<short>, void>' requested here
        : node(new ConstNode<signed short>(value))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:376:9: error: delete called on non-final 'Stats::ConstNode<short>' that has virtual functions but non-virtual
      destructor [-Werror,-Wdelete-non-virtual-dtor]
      { delete _M_ptr; }
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:371:7: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::ConstNode<short> *,
      __gnu_cxx::_S_atomic>::_M_dispose' requested here
      _Sp_counted_ptr(_Ptr __p) noexcept
      ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:584:20: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::ConstNode<short> *,
      __gnu_cxx::_S_atomic>::_Sp_counted_ptr' requested here
              _M_pi = new _Sp_counted_ptr<_Ptr, _Lp>(__p);
                          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<short> *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<short> *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::ConstNode<short>, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3098:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::ConstNode<short>, void>' requested here
        : node(new ConstNode<signed short>(value))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:588:8: error: delete called on non-final 'Stats::ConstNode<unsigned short>' that has virtual functions but
      non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor]
              delete __p;
              ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<unsigned short> *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<unsigned short> *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::ConstNode<unsigned short>, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3106:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::ConstNode<unsigned short>, void>' requested here
        : node(new ConstNode<unsigned short>(value))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:376:9: error: delete called on non-final 'Stats::ConstNode<unsigned short>' that has virtual functions but
      non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor]
      { delete _M_ptr; }
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:371:7: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::ConstNode<unsigned short> *,
      __gnu_cxx::_S_atomic>::_M_dispose' requested here
      _Sp_counted_ptr(_Ptr __p) noexcept
      ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:584:20: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::ConstNode<unsigned short> *,
      __gnu_cxx::_S_atomic>::_Sp_counted_ptr' requested here
              _M_pi = new _Sp_counted_ptr<_Ptr, _Lp>(__p);
                          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<unsigned short> *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<unsigned short> *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::ConstNode<unsigned short>, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3106:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::ConstNode<unsigned short>, void>' requested here
        : node(new ConstNode<unsigned short>(value))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:588:8: error: delete called on non-final 'Stats::ConstNode<int>' that has virtual functions but non-virtual
      destructor [-Werror,-Wdelete-non-virtual-dtor]
              delete __p;
              ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<int> *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<int> *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::ConstNode<int>, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3114:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::ConstNode<int>, void>' requested here
        : node(new ConstNode<signed int>(value))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:376:9: error: delete called on non-final 'Stats::ConstNode<int>' that has virtual functions but non-virtual
      destructor [-Werror,-Wdelete-non-virtual-dtor]
      { delete _M_ptr; }
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:371:7: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::ConstNode<int> *,
      __gnu_cxx::_S_atomic>::_M_dispose' requested here
      _Sp_counted_ptr(_Ptr __p) noexcept
      ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:584:20: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::ConstNode<int> *,
      __gnu_cxx::_S_atomic>::_Sp_counted_ptr' requested here
              _M_pi = new _Sp_counted_ptr<_Ptr, _Lp>(__p);
                          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<int> *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<int> *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::ConstNode<int>, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3114:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::ConstNode<int>, void>' requested here
        : node(new ConstNode<signed int>(value))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:588:8: error: delete called on non-final 'Stats::ConstNode<unsigned int>' that has virtual functions but
      non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor]
              delete __p;
              ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<unsigned int> *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<unsigned int> *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::ConstNode<unsigned int>, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3122:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::ConstNode<unsigned int>, void>' requested here
        : node(new ConstNode<unsigned int>(value))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:376:9: error: delete called on non-final 'Stats::ConstNode<unsigned int>' that has virtual functions but
      non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor]
      { delete _M_ptr; }
        ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:371:7: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::ConstNode<unsigned int> *,
      __gnu_cxx::_S_atomic>::_M_dispose' requested here
      _Sp_counted_ptr(_Ptr __p) noexcept
      ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:584:20: note: in instantiation of member function 'std::_Sp_counted_ptr<Stats::ConstNode<unsigned int> *,
      __gnu_cxx::_S_atomic>::_Sp_counted_ptr' requested here
              _M_pi = new _Sp_counted_ptr<_Ptr, _Lp>(__p);
                          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<unsigned int> *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<unsigned int> *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::ConstNode<unsigned int>, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3122:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::ConstNode<unsigned int>, void>' requested here
        : node(new ConstNode<unsigned int>(value))
          ^
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.cc:29:
In file included from build/X86_MOESI_AMD_Base/mem/ruby/common/Address.hh:37:
In file included from build/X86_MOESI_AMD_Base/base/types.hh:43:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/memory:81:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:52:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:588:8: error: delete called on non-final 'Stats::ConstNode<long>' that has virtual functions but non-virtual
      destructor [-Werror,-Wdelete-non-virtual-dtor]
              delete __p;
              ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:595:4: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<long> *>' requested here
        : __shared_count(__p)
          ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr_base.h:1079:17: note: in instantiation of function template specialization
      'std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<Stats::ConstNode<long> *>' requested here
        : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
                       ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/shared_ptr.h:129:25: note: in instantiation of function template specialization 'std::__shared_ptr<Stats::Node,
      __gnu_cxx::_S_atomic>::__shared_ptr<Stats::ConstNode<long>, void>' requested here
        shared_ptr(_Yp* __p) : __shared_ptr<_Tp>(__p) { }
                               ^
build/X86_MOESI_AMD_Base/base/statistics.hh:3130:11: note: in instantiation of function template specialization 'std::shared_ptr<Stats::Node>::shared_ptr<Stats::ConstNode<long>, void>' requested here
        : node(new ConstNode<signed long>(value))
          ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
scons: *** [build/X86_MOESI_AMD_Base/mem/ruby/common/Address.o] Error 1
scons: building terminated because of errors.

I only observe this error using clang.

I use LLVM because the final binaries are in some way better optimized, and they have a better performance compared to the gcc ones.

error: implicit conversion from 'int' to 'Element'

Hi, I am a beginner user of gem5. When I try to compile gem5, I got this error and many similar ones:

build/ARM/arch/arm/generated/exec-ns.cc.inc:189454:39: error: implicit conversion from 'int' to
      'Element' (aka 'signed char') changes value from 128 to -128 [-Werror,-Wconstant-conversion]

,which prevent me from compilation.

How could I overcome this error without any problem?

NOTE: I am compiling on OSX 10.12.4

Thanks and best regards,

Thanh C. Tran

generateDiassembly

In the arm arch, the output of diassembly has some mistakes. The diassembly can only output misc_reg index, like x461. The "dest" varible in every static_inst object is not relative, so the output is wrong. I use some tricks to fix this.

GitHub Actions Runner VMs are limited to 60GB Disk Space. This means disabling PARSEC Tests

Our GitHub self-hosted Actions Runners run within VMs. These VMs are limited to a 60GB of disk image space. This is sufficient for most tests, but if running PARSEC, we are required to download the PARSEC Disk Image resource, v1.0.0 (http://resources.gem5.org/resources/x86-parsec?version=1.0.0). Unzipped this image is 33GB, which pushes the VM to exaust all it's disk image space. This crashes the VM.

Pull Request #164 disables the tests which use PARSEC.

The PARSEC tests can be re-incorporated when we are able to increase the disk image size on these VMs.

Linux kernel booted on x86 Full System mode

Hi, I'm trying to boot x86 gem5 full system simulation with the latest Linux kernel version 4.x
but didn't work.
I built kernel version 4.12.3,4.15.12 and 3.11 for testing, and build with default config : make defconfig
can someone share your kernel configuration setup that played well on Gem5 ?

thanks.

Potential segmentation fault in /src/cpu/pred/ltage.cc:556

In the update function when trying to allocate new entries, is it possible that changing the value of X (line 556 558) might result in potential segfault in (line 562)? To me it seems that there is no any bound checking.

            int Y = nrand &
                ((ULL(1) << (nHistoryTables - bi->hitBank - 1)) - 1);
            int X = bi->hitBank + 1;
            if (Y & 1) {
                X++;
                if (Y & 2)
                    X++;
            }
            // No entry available, forces one to be available
            if (min > 0) {
                gtable[X][bi->tableIndices[X]].u = 0;
            }

Is there a limit to the number of in-flight memory instructions in Minor CPU?

I have configured the Minor CPU with only two FUs (ALU and memory). Because of this, the size of the inFlightInsts queue is very small, and I am getting a warning: build/NIOSII/cpu/minor/buffers.hh:442: warn: system.cpu.execute.inFlightInsts0: No space to push data into queue of capacity 2, pushing anyway.

Upon further inspection, it seems that this is caused by 1) construction of the inFlightInsts queue assumes that each FU will have a maximum of opLat instructions in flight and 2) memory instructions are considered "in flight" after exiting the FU until receiving a memory response. MinorDefaultMemFU has a configured opLat of 1, but I can see via the MinorTrace debug flag that more than 1 memory instruction may be in the inFlightInsts queue at a time.

So I have a question: Is there some mechanism to limit the number of memory instructions in the inFlightInsts queue? Since I have done some tinkering, I want to make sure I have not broken such a mechanism if one exists. In my inspection of Execute::issue, Execute::commit, and Execute::commitInst, I did not see such a limit being enforced. If the above warning is supposed to be "normal", then perhaps it should be a warn_once so it does not spam the terminal.

potential pull request

Hi,
our team is adding some new functions into GEM5 for tracing branch predictor and cache information（cache reuse/stack distance,branch resolution time,instruction critical path,etc.）, which is our CPI module's input. In the future, we hope this module can be a tool for CPU performance evaluation.
as front-end of our tool, we hope the additional tracing code in GEM5 to be official and reliable. so, will the pull request be acceptable?

Thanks,
Wang Wei.

Build error when linking gem5.opt

Hi,

I encountered an error when building gem5, saying "error adding symbols: DSO missing from command line".
How to solve this?

[ LINK] -> RISCV/gem5.opt
/home/kinseng/chipyard/.conda-env/bin/../lib/gcc/x86_64-conda-linux-gnu/12.2.0/../../../../x86_64-conda-linux-gnu/bin/ld: build/RISCV/proto/inst_dep_record.pb.o: undefined reference to symbol '_ZN4absl12lts_2023012512log_internal17MakeCheckOpStringIllEEPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEET_T0_PKc'
/home/kinseng/chipyard/.conda-env/bin/../lib/gcc/x86_64-conda-linux-gnu/12.2.0/../../../../x86_64-conda-linux-gnu/bin/ld: /home/kinseng/chipyard/.conda-env/lib/libabsl_log_internal_check_op.so.2301.0.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
scons: *** [build/RISCV/gem5.opt] Error 1
scons: building terminated because of errors.

Fix style in RISC-V isa file

https://github.com/gem5/gem5/blob/dceabe5fda598937b00959cc648fb7f2fbbe950a/src/arch/riscv/isa.hh#L73C19-L73C19

This should be rvType instead of rv_type.

RISC-V full system simulation not working within systemc (gem5 within systemc)

Describe the bug
Running a riscv-fs example within systemc using gem5 within systemc leads to a segmentation fault:

        SystemC 2.3.4-Accellera --- Aug  4 2023 09:56:03
        Copyright (c) 1996-2022 by all Contributors,
        ALL RIGHTS RESERVED
Global frequency set at 1000000000000 ticks per second
============================================================
EventQueue Dump  (cycle 0)
------------------------------------------------------------
<No Events>
============================================================
build/ALL/sim/kernel_workload.cc:46: info: kernel located at: /root/.cache/gem5/riscv-bootloader-vmlinux-5.10

Info: board.platform.rtc: Real-time clock set to Sun Jan  1 00:00:00 2012
board.platform.terminal: Listening for connections on port 3456
build/ALL/base/statistics.hh:279: warn: One of the stats is a legacy stat. Legacy stat is a stat that does not belong to any statistics::Group. Legacy stat is deprecated.
build/ALL/base/statistics.hh:279: warn: One of the stats is a legacy stat. Legacy stat is a stat that does not belong to any statistics::Group. Legacy stat is deprecated.
board.remote_gdb: Listening for connections on port 7000
build/ALL/arch/riscv/linux/fs_workload.cc:51: info: Loading DTB file: m5out/device.dtb at address 0x87e00000
sc_module.cc:257: info: Entering event queue @ 0.  Starting simulation...
gem5 has encountered a segmentation fault!

--- BEGIN LIBC BACKTRACE ---
/root/mnt/gem5/build/ALL/libgem5_debug.so(_ZN4gem515print_backtraceEv+0x1f)[0x7f28a5a810f8]
/root/mnt/gem5/build/ALL/libgem5_debug.so(+0x65447ad)[0x7f28a5a9e7ad]
/lib64/libc.so.6(+0x4eb50)[0x7f289e67fb50]
/root/mnt/gem5/build/ALL/libgem5_debug.so(_ZN4gem514SignalSinkPortIbE3setERKb+0x1b)[0x7f28a51fe527]
/root/mnt/gem5/build/ALL/libgem5_debug.so(_ZN4gem516SignalSourcePortIbE3setERKb+0x35)[0x7f28a51fe0d5]
/root/mnt/gem5/build/ALL/libgem5_debug.so(_ZN4gem516IntSourcePinBase5raiseEv+0x23)[0x7f28a51fdd09]
/root/mnt/gem5/build/ALL/libgem5_debug.so(_ZN4gem58RiscvRTC3RTC11handleEventEv+0x75)[0x7f28a55ac6fb]
/root/mnt/gem5/build/ALL/libgem5_debug.so(_ZN4gem58MC1468188RTCEvent7processEv+0x108)[0x7f28a51a2858]
/root/mnt/gem5/build/ALL/libgem5_debug.so(_ZN4gem510EventQueue10serviceOneEv+0x10b)[0x7f28a5a92451]
./gem5.debug.sc[0x4294d9]
./gem5.debug.sc[0x44bec3]
./gem5.debug.sc[0x44cd01]
./gem5.debug.sc[0x44cf5d]
./gem5.debug.sc[0x41d9bd]
./gem5.debug.sc[0x42ff54]
/lib64/libc.so.6(__libc_start_main+0xe5)[0x7f289e66bd85]
./gem5.debug.sc[0x41ba1e]
--- END LIBC BACKTRACE ---
For more info on how to address this issue, please visit https://www.gem5.org/documentation/general_docs/common-errors/ 

When looking into the issue using gdb, this is the demangled stacktrace of the segfault:

#0  0x00007ffff5bc6527 in gem5::SignalSinkPort<bool>::set (this=0x0, new_state=@0x7fffffffdf8f: true) at build/ALL/sim/signal.hh:60
#1  0x00007ffff5bc60d5 in gem5::SignalSourcePort<bool>::set (this=0x14a8920, new_state=@0x7fffffffdf8f: true) at build/ALL/sim/signal.hh:108
#2  0x00007ffff5bc5d09 in gem5::IntSourcePinBase::raise (this=0x14a8920) at build/ALL/dev/intpin.hh:89
#3  0x00007ffff5f746fb in gem5::RiscvRTC::RTC::handleEvent (this=0x14a8450) at build/ALL/dev/riscv/rtc.cc:67
#4  0x00007ffff5b6a858 in gem5::MC146818::RTCEvent::process (this=0x14a8480) at build/ALL/dev/mc146818.cc:327
#5  0x00007ffff645a451 in gem5::EventQueue::serviceOne (this=0x9c75c0) at build/ALL/sim/eventq.cc:249
#6  0x00000000004294d9 in Gem5SystemC::Module::eventLoop (this=0x7fffffffe300) at sc_module.cc:241
#7  0x000000000044bec3 in sc_core::sc_simcontext::simulate(sc_core::sc_time const&) ()
#8  0x000000000044cd01 in sc_core::sc_start(sc_core::sc_time const&, sc_core::sc_starvation_policy) ()
#9  0x000000000044cf5d in sc_core::sc_start() ()
#10 0x000000000041d9bd in sc_main (argc=2, argv=0x9cfba0) at main.cc:402
#11 0x000000000042ff54 in sc_elab_and_sim ()
#12 0x00007fffef033d85 in __libc_start_main () from /lib64/libc.so.6
#13 0x000000000041ba1e in _start ()

This issue only occurs when using the gem5 within systemc coupling (util/systemc/gem5_within_systemc) or the SystemC TLM couplings. When running the examples just using the normal gem5 executable e.g. gem5.debug / gem5.opt it works as expected.

The ARM gem5_library examples e.g. arm-ubuntu-run.py work as expected within systemc. Therefore I assume the error is somewhere within the MC146818 or RiscvRTC component, which are used in RiscvBoard.

Affects version

gem5 23.0.0.1 , didn't try other versions

gem5 Modifications

No Modifications of gem5

To Reproduce

• Build gem5 and libgem5 e.g.

scons --with-cxx-config --without-tcmalloc USE_SYSTEMC=0 --duplicate-sources build/ALL/gem5.debug -j$(nproc)
scons --with-cxx-config --without-python --without-tcmalloc USE_SYSTEMC=0 --duplicate-sources build/ALL/libgem5_debug.so -j$(nproc)

• Build gem5_within_systemc (see util/systemc/gem5_within_systemc/README for details) i.e.
  • Build external systemc SystemC

wget -q https://github.com/accellera-official/systemc/archive/refs/tags/2.3.4.tar.gz -O systemc-2.3.4.tar.gz \
    && tar -xf systemc-2.3.4.tar.gz
cd systemc-2.3.4
.config/bootstrap
mkdir build
cd build
../configure --prefix=/opt/systemc-2.3.4  --disable-shared --build=x86_64-pc-linux-gnu   \
    && make -j$(nproc) \
    && make install

Adapt the Makefile in util/systemc/gem5_within_systemc to point to systemc and do make

Now it is possible to compare gem5 with systemc to a simulation without system:
../../../build/ALL/gem5.debug ../../../configs/example/gem5_library/riscvmatched-fs.py --> works as expected

Now run gem5 within systemc using the created config.ini
./gem5.debug.sc m5out/config.ini --> leads to degmenation fault at the top

Expected behavior
No segmentation fault as when using the normal gem5 executable e.g. gem5.debug / gem5.opt

Host Operating System
Rocky 8.6

Host ISA
RISC-V

Compiler used
gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-18)

printing bubble instruction in Minor CPU causes segfault

It appears that printing a bubble instruction in the Minor CPU causes a segfault.

Steps to reproduce:

1. Run gem5 with the Minor CPU and the 'Branch' or 'Fetch' debug flags.
2. Cause an interrupt so that minor::Execute::takeInterrupt is called.
3. Observe a segfault at src/cpu/minor/dyn_inst.cc:116

If the 'Branch' debug flag is used, then the segfault is caused by the DPRINTF statement at src/cpu/minor/execute.cc:320; otherwise, if the 'Fetch' debug flag is used, then the segfault is caused by the DPRINTF statement at src/cpu/minor/fetch1.cc:513.

I am using gem5 version 22.1.0.0, so I apologize if this is already fixed in the current version.

RISC-V RVV vset*vl* instructions can execute bad in out-of-order (O3) mode

Describe the bug
RVV vset*vl* instructions can be executed bad in out-of-order (O3) mode. If vset*vl* is in mis-predicted branch it changes the 'VL' value in decoder and the vector instructions afterwards are decoded/executed in correspondence with 'VL' value which was set in squashed instruction.

Affects version
Found in arch-riscv: Relation chain on RVV support #83 PR.

To Reproduce
The reproducer is in https://github.com/vmskv/gem5/tree/vmskv/rvv_bad_o3_vsetvl_execuion/riscv_o3_bad_vsetvl_execution_reproducer
The steps to reproduce are in README.txt

Expected behavior
If vset*vl* is squashed the last previous correct 'VL' value should be used to decode the vector instructions.

Host Operating System
Ubuntu 20.04

Guest ISA
RISC-V.

Linux kernel boot on x86 full system (FS) with --cpu-type=DerivO3CPU fails with: "Kernel panic - not syncing: Attempted to kill the idle task!"

fbe6307

Boot works if I remove --cpu-type=DerivO3CPU.

Possible same on mailing list: https://www.mail-archive.com/[email protected]/msg14062.html but DeriveO3CPU not mentioned so I'm not sure.

Automated setup to reproduce: https://github.com/************/linux-kernel-module-cheat/tree/cc347bbef76687f71e19a5e75f8a92f9e8ad6332#gem5-change-system-parameters

Full gem5 command:

M5_PATH='/data/git/linux-kernel-module-cheat/gem5/gem5-system' '/data/git/linux-kernel-module-cheat/gem5/gem5/build/X86/gem5.opt'  '/data/git/linux-kernel-module-cheat/gem5/gem5/configs/example/fs.py' --command-l
ine='earlyprintk=ttyS0 console=ttyS0 lpj=7999923 root=/dev/hda nokaslr norandmaps printk.devkmsg=on printk.time=y' --disk-image='/data/git/linux-kernel-module-cheat/buildroot/output.x86_64-gem5~/images/rootfs.ext
2' --kernel='/data/git/linux-kernel-module-cheat/buildroot/output.x86_64-gem5~/build/linux-custom/vmlinux' --num-cpus=1  --caches --l1d_size=1024 --l2cache --l2_size=1024 --l3_size=1024 --cpu-type=DerivO3CPU

dmesg excerpt:

    [    0.010765] BUG: unable to handle kernel NULL pointer dereference at 000000000000022e                 
    [    0.010825] IP: text_poke_early+0x1f/0x27        
    [    0.010855] PGD 0 P4D 0                          
    [    0.010879] Oops: 0002 [#1] SMP PTI              
    [    0.010905] Modules linked in:                   
    [    0.010931] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.15.0 #1                                       
    [    0.010971] Hardware name:  , BIOS  06/08/2008   
    [    0.011000] RIP: 0010:text_poke_early+0x1f/0x27  
    [    0.011000] RSP: 0000:ffffffff81c03dd0 EFLAGS: 000008b8                                               
    [    0.011000] RAX: 0000000000000291 RBX: ffffffff8200a228 RCX: 0000000000000000                         
    [    0.011000] RDX: 000000000000026c RSI: ffffffff81c03de9 RDI: 000000000000026c                         
    [    0.011000] RBP: ffffffff81c03de2 R08: ffffffff810145eb R09: 0000000000000005                         
    [    0.011000] R10: ffffffff81c03de2 R11: ffffffff81c03de2 R12: ffffffff820154c4                         
    [    0.011000] R13: ffffffff81fab2e0 R14: 0000000000000000 R15: 0000000000000000                         
    [    0.011000] FS:  0000000000000000(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000              
    [    0.011000] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033                                         
    [    0.011000] CR2: 000000000000022e CR3: 0000000001c0a000 CR4: 00000000000006b0                         
    [    0.011000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000                         
    [    0.011000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000000                         
    [    0.011000] Call Trace:                          
    [    0.011000]  ? apply_paravirt.part.1+0x74/0x82   
    [    0.011000]  ? vprintk_emit+0x201/0x213          
    [    0.011000]  ? printk+0x3e/0x46                  
    [    0.011000]  ? free_reserved_area+0x103/0x112    
    [    0.011000]  ? alternative_instructions+0xbf/0xcf
    [    0.011000]  ? check_bugs+0x1be/0x2f2            
    [    0.011000]  ? start_kernel+0x4ac/0x4c3          
    [    0.011000]  ? secondary_startup_64+0xa5/0xb0    
    [    0.011000] Code: 30 eb ba 31 c0 c3 b8 01 00 00 00 c3 49 89 f8 48 89 d1 9c 58 66 66 90 66 90 48 89 c2 fa 66 66 90 66 66 90 f3 a4 48 89 d7 57 9d 66 <66> 90 66 90 4c 89 c0 c3 41 57 41 56 41 55 41 54 55 53 48 89 fb                                                 
    [    0.011000] RIP: text_poke_early+0x1f/0x27 RSP: ffffffff81c03dd0                                      
    [    0.011000] CR2: 000000000000022e                
    [    0.011000] ---[ end trace 6d53c1c17a70e53c ]--- 
    [    0.011000] Kernel panic - not syncing: Attempted to kill the idle task!                              
    [    0.011000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!

Is Branch Predictor working for Minor and DerivO3?

I'm having problem retrieving the BTB hit rate for both Minor and DerivO3.
The problem for Minor is that, inside of the branch predictor bpred_unit,cc, it uses functions like static_inst.isControl(), static_inst.isConditional() etc, which use instruction flags to decide if this is a branch. While at the fetch stage when we do prediction, the instruction flags have not been decided yet and always has a default all-zero.

Previously I brute force one program to get all of its branch PCs (conditional, unconditional, branch etc), creating a list. Every time those instructions are called, I just searched those lists.

This works for Minor. But in DeriveO3, there is yet another problem. The function inst->branchTarget() called in decode_impl.hh is simply not implemented. In static_inst.cc, the function simply output a panic.
TheISA::PCState
StaticInst::branchTarget(const TheISA::PCState &pc) const
{
panic("StaticInst::branchTarget() called on instruction "
"that is not a PC-relative branch.");
M5_DUMMY_RETURN;
}

I'm wondering if there's something wrong with my configuration. Since the main objective for me to run gem5 is to get a BTB hit rate, I'm in urgent need to make this work. Thank you so much for your help!

Unable to access some gem5 resources when using Resource()

Summary:
The error "Resource with name 'resource_name' does not exist" occurs with some gem5 resources. This includes x86-matrix-multiply-omp, x86-bubblesort, x86-floatmm, riscv-bubblesort, and arm-bubblesort. The error can be replicated by attempting to obtain a resource with Resource("resource_name") in a Python script for setting up a simulation. The fix that I found for x86-matrix-multiply-omp was to change the url for x86-matrix-multiply-omp in the resources.json file. This would not work for x86-bubblesort and x86-floatmm, as they were entirely absent from resources.json.

Detailed:
When attempting to access a number of gem5 resources with Resource(resource_name), the following error occurs:

Exception: Error: Resource with name 'x86-matrix-multiply-omp' does not exist

At:
  build/X86/python/gem5/resources/downloader.py(362): get_resources_json_obj
  build/X86/python/gem5/resources/resource.py(168): __init__
  materials/testing-resources/x86_matrix_multiply_omp_example.py(22): <module>
  build/X86/python/m5/main.py(597): main

I used x86-matrix-multiply-omp for testing, but other affected resources include x86-bubblesort, x86-floatmm, and riscv-bubblesort.

I was able to get past this error message by changing the link in _get_resources_json_uri() to
https://raw.githubusercontent.com/gem5/gem5-resources/stable/resources.json. It now looks like this:

def _get_resources_json_uri() -> str:
    #return "https://resources.gem5.org/resources.json"
    return "https://raw.githubusercontent.com/gem5/gem5-resources/stable/resources.json"

After this change, an HTTP 404 error occurred. I attempted to access the url for x86-matrix-multiply-omp in resources.json and observed that no file was hosted there.

To fix this, I set the environment variable for "GEM5_RESOURCE_JSON" to the file path to my local copy of resources.json. Then, I changed the url in the json to a url from the gem5 resources website. The change to the environment variable was in the function definition of _get_resources_json(), in build/X86/python/gem5/resources/downloader.py.

old url:
{url_base}/test-progs/matrix-multiply-omp/x86-matrix-multiply-omp-20230127

where url_base is http://dist.gem5.org/dist/v22-1

new url:
http://dist.gem5.org/dist/develop/test-progs/matrix-multiply-omp/x86-matrix-multiply-omp-20230127 

At this point, the script was able to obtain the resource.

I attempted to use the same fix for x86-floatmm and x86-bubblesort, but they were both absent from the json.

Reporting traps (faults) to GDB in SE mode is broken

While using gem5 in SE mode I realized that reporting traps to GDB (if connected) is broken / missing at least on
POWER / RISC-V.

Consider POWER: https://github.com/gem5/gem5/blob/develop/src/arch/power/faults.cc#L42-L63. trapToGdb returns true is GDB is connected and trap has been reported, otherwise false. But the code in TrapFault::invoke panics if there's a GDB connected and does nothing if there's no GDB at all! I'm pretty sure the logic should be inverse.

On RISC-V (and possibly other architectures as well) there's no such logic at all, look at https://github.com/gem5/gem5/blob/develop/src/arch/riscv/faults.cc, so on RISC-V one does not see software breakpoints hitting at all when connecting GDB to debug program running in gem5.

packet_queue limit too low for huge load/store queues

Describe the bug
The limit in this line is too low for a cu with really large load/store queues:

gem5/src/mem/packet_queue.cc

Line 121 in 48b4788

if (!_disableSanityCheck && transmitList.size() > 128) {

Affects version
All versions (though earlier limit was 100 instead of 128)

gem5 Modifications
When developing a model of the ARM X4 I set LQEntries to 120 and SQEntries to 140 and runs failed at the indicated line. Increasing the limit to 500 allowed the runs to go through. Since the LQ and SQ entries form the actual queue of packets to be sent, exceeding 128 (or 100) here is not unreasonable. The easy fix is to increase the number somewhat, which is what I did. Another possibility is to make this limit a settable parameter. It is certainly true that packet queues in some other places than the cpu-to-dcache queue can reasonably have lower limits. This is why a settable parameter may be better - but that is deeper surgery, and since this is a sanity check, a single global value may do.

To Reproduce
Steps to reproduce the behavior. Please assume starting from a clean repository:

1. Develop on O3 model with sufficiently large values for LQEntries and SQEntries
2. Execute the simulation with a program that can issue a sufficiently large number of non-dependent loads/stores.

(I did not develop a specific test case; I just observed the panics to disappear when I increased the limit, and my runs went through without any apparent ill effect.)

Expected behavior
No panic.

Host Operating System
Ubuntu (not sure of version) Linux kernel 5.4.0-81-generic

Host ISA
X86

Compiler used
State which compiler was used to compile gem5. Please include the compiler version.
gcc-9.3.0 (I believe, though it should not matter)

Additional information
Simulated CPU was ARM DerivO3 specialized using O3_ARM_V9a_x4 from the python script below. (Note: I am not claiming the details correspond to an actual ARM X4, but they seemed to me approximately right.)

#                                                                                                             
# Information about the Cortex X4:                                                                            
#                                                                                                             
#     https://www.androidauthority.com/arm-cortex-x4-explained-3328008                                        
#     https://en.wikipedia.org/wiki/ARM_Cortex-X4                                                             
#     https://fuse.wikichip.org/news/7531/arm-introduces-the-cortex-x4-its-newest-flagship-performance-core   
#                                                                                                             
# v9a drops 32-bit support                                                                                    
#                                                                                                             
#  X4 has:                                                                                                    
#   64Kb L1I and L1D caches                                                                                   
#   2Mb per-processor L2 cache                                                                                
#   up to 32Mb shared L3 cache                                                                                
#   FDIV/FSQRT are pipelined                                                                                  
#   11 cycle branch mispredict penalty (?)                                                                    
#   2-taken branch prediction                                                                                 
#                                                                                                             
#   clock 4.0 GHz according to:                                                                               
#     https://www.theregister.com/2023/05/29/arm_tcs23                                                        
#   but other sources give 3.4 GHz                                                                            
#                                                                                                             
#   8 ALUs (2 handle fancy ops), 4 FPUs, 3 branch units                                                       
#                                                                                                             
#  Pipeline 10 wide, 10 stage                                                                                 
#  ROB size 384 (ignoring fused micro ops)                                                                    
#                                                                                                             
                                                                                                              
from m5.objects import *                                                                                      
                                                                                                              
# Simple ALU Instructions have a latency of 1                                                                 
class O3_ARM_v9a_x4_Simple_Int(FUDesc):                                                                       
    opList = [ OpDesc(opClass='IntAlu', opLat=1) ]                                                            
    count = 6                                                                                                 
                                                                                                              
# Complex ALU instructions have a variable latencies                                                          
class O3_ARM_v9a_x4_Complex_Int(FUDesc):                                                                      
    opList = [ OpDesc(opClass='IntMult', opLat=3, issueLat=1),                                                
               OpDesc(opClass='IntDiv', opLat=12, issueLat=12),                                               
               OpDesc(opClass='IprAccess', opLat=3, issueLat=1) ]                                             
    count = 2                                                                                                 
                                                                                                              
                                                                                                              
# Simple floating point instructions
class O3_ARM_v9a_x4_Simple_FP(FUDesc):                                                                        
    opList = [ OpDesc(opClass='FloatAdd', opLat=2),                                                           
               OpDesc(opClass='FloatCmp', opLat=2),                                                           
               OpDesc(opClass='FloatCvt', opLat=2),                                                           
               OpDesc(opClass='FloatMult', opLat=3) ]                                                         
    count = 3                                                                                                 
                                                                                                              
# Complex floating point and SIMD instructions                                                                
class O3_ARM_v9a_x4_Complex_FP(FUDesc):                                                                       
    opList = [ OpDesc(opClass='SimdAdd', opLat=4),                                                            
               OpDesc(opClass='SimdAddAcc', opLat=4),                                                         
               OpDesc(opClass='SimdAlu', opLat=4),                                                            
               OpDesc(opClass='SimdCmp', opLat=4),                                                            
               OpDesc(opClass='SimdCvt', opLat=3),                                                            
               OpDesc(opClass='SimdMisc', opLat=3),                                                           
               OpDesc(opClass='SimdMult',opLat=5),                                                            
               OpDesc(opClass='SimdMultAcc',opLat=5),                                                         
               OpDesc(opClass='SimdShift',opLat=3),                                                           
               OpDesc(opClass='SimdShiftAcc', opLat=3),                                                       
               OpDesc(opClass='SimdSqrt', opLat=9),                                                           
               OpDesc(opClass='SimdFloatAdd',opLat=5),                                                        
               OpDesc(opClass='SimdFloatAlu',opLat=5),                                                        
               OpDesc(opClass='SimdFloatCmp', opLat=3),                                                       
               OpDesc(opClass='SimdFloatCvt', opLat=3),                                                       
               OpDesc(opClass='SimdFloatDiv', opLat=3),                                                       
               OpDesc(opClass='SimdFloatMisc', opLat=3),                                                      
               OpDesc(opClass='SimdFloatMult', opLat=3),                                                      
               OpDesc(opClass='SimdFloatMultAcc',opLat=1),                                                    
               OpDesc(opClass='SimdFloatSqrt', opLat=9),                                                      
               OpDesc(opClass='FloatAdd', opLat=5),                                                           
               OpDesc(opClass='FloatCmp', opLat=5),                                                           
               OpDesc(opClass='FloatCvt', opLat=5),                                                           
               OpDesc(opClass='FloatDiv', opLat=9),                                                           
               OpDesc(opClass='FloatSqrt', opLat=33),                                                         
               OpDesc(opClass='FloatMult', opLat=4) ]                                                         
    count = 1                                                                                                 
                                                                                                              
# Unified floating point units                                                                                
class O3_ARM_v9a_x4_Unified_FP(FUDesc):                                                                       
    opList = [ OpDesc(opClass='FloatAdd', opLat=2),                                                           
               OpDesc(opClass='FloatCmp', opLat=2),                                                           
               OpDesc(opClass='FloatCvt', opLat=2),                                                           
               OpDesc(opClass='FloatMult', opLat=3),                                                          
               OpDesc(opClass='SimdAdd', opLat=2),                                                            
               OpDesc(opClass='SimdAddAcc', opLat=2),                                                         
               OpDesc(opClass='SimdAlu', opLat=2),                                                            
               OpDesc(opClass='SimdCmp', opLat=2),                                                            
               OpDesc(opClass='SimdCvt', opLat=3),                                                            
               OpDesc(opClass='SimdMisc', opLat=3),                                                           
               OpDesc(opClass='SimdMult',opLat=3),                                                            
               OpDesc(opClass='SimdMultAcc',opLat=3),                                                         
               OpDesc(opClass='SimdShift',opLat=2),                                                           
               OpDesc(opClass='SimdShiftAcc', opLat=2),                                                       
               OpDesc(opClass='SimdSqrt', opLat=9),                                                           
               OpDesc(opClass='SimdFloatAdd',opLat=2),                                                        
               OpDesc(opClass='SimdFloatAlu',opLat=2),                                                        
               OpDesc(opClass='SimdFloatCmp', opLat=2),                                                       
               OpDesc(opClass='SimdFloatCvt', opLat=3),                                                       
               OpDesc(opClass='SimdFloatDiv', opLat=9),
               OpDesc(opClass='SimdFloatMisc', opLat=3),                                                      
               OpDesc(opClass='SimdFloatMult', opLat=3),                                                      
               OpDesc(opClass='SimdFloatMultAcc',opLat=3),                                                    
               OpDesc(opClass='SimdFloatSqrt', opLat=9),                                                      
               OpDesc(opClass='FloatDiv', opLat=9, issueLat=9),                                               
               OpDesc(opClass='FloatSqrt', opLat=7, issueLat=7) ]                                             
    count = 1                                                                                                 
                                                                                                              
                                                                                                              
# Load/Store Units                                                                                            
class O3_ARM_v9a_x4_Load(FUDesc):                                                                             
    opList = [ OpDesc(opClass='MemRead',opLat=2) ]                                                            
    count = 2                                                                                                 
                                                                                                              
class O3_ARM_v9a_x4_Store(FUDesc):                                                                            
    opList = [OpDesc(opClass='MemWrite',opLat=1) ]                                                            
    count = 3                                                                                                 
                                                                                                              
# Functional Units for this CPU                                                                               
class O3_ARM_v9a_x4_FUP(FUPool):                                                                              
    FUList = [O3_ARM_v9a_x4_Simple_Int(), O3_ARM_v9a_x4_Complex_Int(),                                        
              O3_ARM_v9a_x4_Simple_FP(), O3_ARM_v9a_x4_Complex_FP(),                                          
              O3_ARM_v9a_x4_Load(), O3_ARM_v9a_x4_Store()]                                                    
                                                                                                              
# Bi-Mode Branch Predictor                                                                                    
class O3_ARM_v9a_x4_BP(BranchPredictor):                                                                      
    predType = "bi-mode"                                                                                      
    globalPredictorSize = 16384                                                                               
    globalCtrBits = 2                                                                                         
    choicePredictorSize = 16384                                                                               
    choiceCtrBits = 2                                                                                         
    BTBEntries = 16384                                                                                        
    BTBTagSize = 18                                                                                           
    RASSize = 64                                                                                              
    instShiftAmt = 2                                                                                          
                                                                                                              
class O3_ARM_v9a_x4(DerivO3CPU):                                                                              
    LQEntries = 120                                                                                           
    SQEntries = 140                                                                                           
    LSQDepCheckShift = 4                                                                                      
    LFSTSize = 1024                                                                                           
    SSITSize = 1024                                                                                           
    decodeToFetchDelay = 1                                                                                    
    renameToFetchDelay = 1                                                                                    
    iewToFetchDelay = 1                                                                                       
    commitToFetchDelay = 1                                                                                    
    renameToDecodeDelay = 1                                                                                   
    iewToDecodeDelay = 1                                                                                      
    commitToDecodeDelay = 1                                                                                   
    iewToRenameDelay = 1                                                                                      
    commitToRenameDelay = 1                                                                                   
    commitToIEWDelay = 1                                                                                      
    fetchWidth = 16                                                                                           
    fetchBufferSize = 64                                                                                      
    fetchQueueSize = 32                                                                                       
    fetchToDecodeDelay = 1                                                                                    
    decodeWidth = 10                                                                                          
    decodeToRenameDelay = 1                                                                                   
    renameWidth = 10 # 6
    renameToIEWDelay = 1                                                                                      
    issueToExecuteDelay = 1                                                                                   
    dispatchWidth = 10                                                                                        
    issueWidth = 12                                                                                           
    wbWidth = 10                                                                                              
    fuPool = O3_ARM_v9a_x4_FUP()                                                                              
    iewToCommitDelay = 1                                                                                      
    renameToROBDelay = 1                                                                                      
    commitWidth = 10 # 6                                                                                      
    squashWidth = 10                                                                                          
    trapLatency = 13                                                                                          
    backComSize = 10                                                                                          
    forwardComSize = 10                                                                                       
    numPhysIntRegs = 256                                                                                      
    numPhysFloatRegs = 256                                                                                    
    numIQEntries = 128                                                                                        
    numROBEntries = 384                                                                                       
                                                                                                              
    switched_out = False                                                                                      
    branchPred = O3_ARM_v9a_x4_BP()                                                                           
                                                                                                              
# Instruction Cache                                                                                           
class O3_ARM_v9a_x4_ICache(BaseCache):                                                                        
    hit_latency = 4                                                                                           
    response_latency = 4                                                                                      
    probe_latency = 4                                                                                         
    mshrs = 2                                                                                                 
    tgts_per_mshr = 20                                                                                        
    size = '64kB'                                                                                             
    assoc = 4                                                                                                 
    is_top_level = 'true'                                                                                     
                                                                                                              
# Data Cache                                                                                                  
class O3_ARM_v9a_x4_DCache(BaseCache):                                                                        
    hit_latency = 4                                                                                           
    response_latency = 4                                                                                      
    probe_latency = 4                                                                                         
    mshrs = 16                                                                                                
    tgts_per_mshr = 20                                                                                        
    size = '64kB'                                                                                             
    assoc = 4                                                                                                 
    write_buffers = 90                                                                                        
    is_top_level = 'true'                                                                                     
                                                                                                              
# TLB Cache                                                                                                   
# Use a cache as a L2 TLB                                                                                     
class O3_ARM_v9a_x4_WalkCache(BaseCache):                                                                     
    hit_latency = 4                                                                                           
    response_latency = 4                                                                                      
    probe_latency = 4                                                                                         
    mshrs = 8                                                                                                 
    tgts_per_mshr = 20                                                                                        
    size = '4kB'                                                                                              
    assoc = 8                                                                                                 
    write_buffers = 16                                                                                        
    is_top_level = 'true'                                                                                     
                                                                                                              
                                                                                                              
# L2 Cache
class O3_ARM_v9a_x4_L2(BaseCache):                                                                            
    hit_latency = 5                                                                                           
    response_latency = 5                                                                                      
    probe_latency = 5                                                                                         
    mshrs = 16                                                                                                
    tgts_per_mshr = 20                                                                                        
    size = '512kB'                                                                                            
    assoc = 8                                                                                                 
    write_buffers = 8                                                                                         
    prefetch_on_access = 'true'                                                                               
    # Simple stride prefetcher                                                                                
    prefetcher = StridePrefetcher(degree=8, latency = 1)                                                      
    tags = RandomRepl()                                                                                       
                                                                                                              
# L2 Cache within a system that has L3                                                                        
class O3_ARM_v9a_x4_L2forL3(BaseCache):                                                                       
    hit_latency = 5                                                                                           
    response_latency = 5                                                                                      
    probe_latency = 5                                                                                         
    mshrs = 16                                                                                                
    tgts_per_mshr = 20                                                                                        
    size = '512kB'                                                                                            
    assoc = 8                                                                                                 
    write_buffers = 8                                                                                         
    prefetch_on_access = 'true'                                                                               
    # Simple stride prefetcher                                                                                
    prefetcher = StridePrefetcher(degree=8, latency = 1)                                                      
    tags = LRU()                                                                                              
                                                                                                              
# L3 Cache                                                                                                    
class O3_ARM_v9a_x4_L3(BaseCache):                                                                            
    hit_latency = 19                                                                                          
    response_latency = 19                                                                                     
    probe_latency = 19                                                                                        
    mshrs = 16                                                                                                
    tgts_per_mshr = 20                                                                                        
    size = '4MB'                                                                                              
    assoc = 16                                                                                                
    write_buffers = 8                                                                                         
    prefetch_on_access = 'true'                                                                               
    # Simple stride prefetcher                                                                                
    prefetcher = StridePrefetcher(degree=8, latency = 1)                                                      
    tags = LRU()                                                                                              

repetition problem of (begin simulation ..... and simulation) in the stats.txt file

GPU Failure in the Daily Tests

Currently, the long gpu tests are failing in our dailies. This failure can be seen here (https://github.com/gem5/gem5/actions/runs/5653802586/job/15319989256). In order to recreate this, you can run the following code below, though all 4 suites in the tests fail. These fail after the inclusion of pull request 101 (#101)

scons build/VEGA_X86/gem5.opt
build/VEGA_X86/gem5.opt configs/example/ruby_gpu_random_test.py --test-length 50000 --num-dmas 0

When you run this, we receive the following output, followed by a backtrace output:

src/mem/dram_interface.cc:690: warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (1024 Mbytes)
src/cpu/testers/gpu_ruby_test/protocol_tester.cc:140: warn: Data race check is not enabled
src/base/statistics.hh:279: warn: One of the stats is a legacy stat. Legacy stat is a stat that does not belong to any statistics::Group. Legacy stat is deprecated.
src/sim/simulate.cc:194: info: Entering event queue @ 0.  Starting simulation...
      1: global: Episode 0
src/cpu/testers/gpu_ruby_test/address_manager.cc:391: warn: Expected return values are:
         0
src/cpu/testers/gpu_ruby_test/tester_thread.cc:388: warn: GpuWavefront(TesterThread ID = 0, CU ID = 0): Atomic Op returned unexpected value
        Episode 0
        Lane ID 0
        Address [0x31884, line 0x31880]
        Atomic Op's return value 1

src/cpu/testers/gpu_ruby_test/protocol_tester.cc:345: panic: GPU Ruby Tester: Failed!
Memory Usage: 1358852 KBytes
Program aborted at tick 1537

aarch64, AES instructions

AESE AESD AESMC AESIMC seem not supported by gem5.

New HashHelper tests not compiling with gcc-7.5.0

I am encountering a compilation problem with the new HashHelper unit-tests 1:

unordered_map.h:133:55: error: 'value' is not a member of 'std::__not_<std::__and_<std::__is_fast_hash<std::hash<std::tuple<int, bool, int**, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > (*)(float)> > >, std::__detail::__is_noexcept_hash<std::tuple<int, bool, int**, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > (*)(float)>, std::hash<std::tuple<int, bool, int**, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > (*)(float)> > > > >' using node_type = typename _Hashtable::node_type;

The problem doesn't seem to be present in newer versions of gcc so I am just changing the version. However we do support gcc-7 in gem5 so either we work around the problem or we deprecate gcc-7 support @BobbyRBruce @powerjg.
gcc-7 is default compiler for Ubuntu18.04 which is past its EOL anyway so I believe it is a reasonable solution

RISC-V fails to compile

I'm trying to compile current develop (618b2a6) for RISC-V (scons build/RISCV/gem5.debug) and the compilation fails:

 [     CXX] RISCV/debug/PMP.cc -> .do
 [ISA DESC] src/arch/riscv/isa/main.isa -> RISCV/arch/riscv/generated/decoder-g.cc.inc, RISCV/arch/riscv/generated/decoder-ns.cc.inc, RISCV/arch/riscv/generated/decode-method.cc.inc, RISCV/arch/riscv/generated/decoder.hh, RISCV/arch/riscv/generated/decoder-g.hh.inc, RISCV/arch/riscv/generated/decoder-ns.hh.inc, RISCV/arch/riscv/generated/exec-g.cc.inc, RISCV/arch/riscv/generated/exec-ns.cc.inc, RISCV/arch/riscv/generated/decoder.cc, RISCV/arch/riscv/generated/inst-constrs.cc, RISCV/arch/riscv/generated/generic_cpu_exec.cc
In file included from /redacted/gem5/build/RISCV/arch/riscv/isa/main.isa:1:
In file included from /redacted/gem5/build/RISCV/arch/riscv/isa/formats/formats.isa:1:
At 0:
Error including file "/redacted/gem5/build/RISCV/arch/riscv/isa/formats/bs.isa"
scons: *** [build/RISCV/arch/riscv/generated/decoder.cc] Explicit exit, status 1
scons: building terminated because of errors.
*** Summary of Warnings ***
Warning: Couldn't find HDF5 C++ libraries. Disabling HDF5 support.

Reverting commit 4dccd7d "arch-riscv: Add BS format isa" fixes the problem for me.

run result in gem5

hello, please help me;
i need to run the parsec benchmarck in gem5
I copied parsec in the .img image and i used the following command:
sudo scons FULL-SYSTEM = 1 build / ARM / gem5.opt -disk-image = expanded-linux-aarch32-ael.img -kernel = vmlinux-aarch32-ll-20131205 -script =. / path / script.rcS
with a .rcs script for each application for example (blackscholes), and I found this result for all parsec applications:

-sh: ./blackscholes: Permission denied

Create checkpointing tests for different ISAs, caches (Ruby/Classic), SE/FS, multicore

Checkpointing in gem5 is easy to break during development. Only have four tests currently utilizes checkpointing:

1. An SE mode RISC-V checkpoint save, with classic cache, 1-core
2. An SE mode RISC-V checkpoint restore, with classic cache, 1-core (restored with checkpoint from 1.
3. A checkpoint save for SimPoints, 1-core
4. A checkpoint restore for Simpoints, 1-core

The Simpoint checkpoints are somewhat tangential to this discussion and can be ignored for now. The SE Mode RISC-V checkpoint tests are more meaningful. While useful, they only test checkpointing on a small subset of possible simulations. Checkpointing bugs with different ISAs, cache types, or in FS mode will not be detected.

Therefore, we should create more tests to test checkpointing in different simulations I suggest the following set of tests to be added:

1. An SE mode ARM checkpoint save, with a Ruby cache, 2-core
2. A restore of 1.
3. An SE mode X86 checkpoint save, with a different classic cache, 4-core
4. A restore of 3.
5. A FS X86 checkpoint save, with a Ruby cache, 4 core
6. A restore of 6.

I believe these 6 tests probably cover enough ground for us right now. As a bonus, i'd add simple SE mode tests for the remaining ISAs.

Please put all the configs somewhere in the "tests/gem5" directory. Though the current configs are in "configs/example/gem5_library/checkpoints", this is because these were written as example scripts, not tests scripts. What is proposed here are pure tests.

Note No. 1: Use the Simulators's to_ticks for the FS mode tests. There's no reason these tests should run for that many ticks before restoring a checkpoint. These tests should be fast

Note No. 2: As you can see in the current RISC-V and Simpoint checkpointing tests, the "restore" tests download the checkpoint from gem5 Resources. This is because our testing infrastructure can't chain tests or run them in a predictable order. So a "save" test can't be run before "restore" with the "restore" test using the save. This is an unfortunate limitation which we use gem5 Resources to get around.

README on gem5-resources src describes how to build and not what a Resource is. Causes issues on resources.gem5.org

The gem5-resource source code has a README.md that often describes how that Resource was built, etc. but not what the Resource is, or any other information that might be more helpful to someone viewing the Resource on the gem5 Resources website. This issue is articulated on the website through the README tab of a Resource.

A potential solution for this would be:

• Change the logic of the README tab to not display the README.md files of the gem5-resources src.
• Move the 1-2 sentence Description of the Resource from the metadata section (on the right side) as the "stand-in" for the Readme tab.
• Explicitly create a section in the metadata for the Source Code of the Resource

Solutions:

1. One idea we discussed was to allow the description to be a link to a README. In case it is a link, then the contents of that file are fetched and displayed instead of the 1-2 sentence description.

Potential downsides of this solution are:

• The "description" field is used to search for Resources.
• The "description" field is used to display a tiny bit of information about a Resource before the user clicks on it, like:

So, to overcome the downsides, searching would have to be able to handle links by parsing through the contents of that link or just not handle links.

2. Another idea is to add a field to the schema ("readme") in which a link to the README of the Resource for the website can be added. If this field exists, the contents of the link are loaded and displayed. If not, then the "description" field is used.

While this is a good idea, it adds two fields with not much information to the schema on how it is resolved, i.e., it does not indicate in the schema that the "description" will not be displayed if the "readme" field exists. Also, adding one field just for the "readme" and not the "changelog" does not make a lot of sense.

However, searching will not have to change with this approach.

3. Another idea is to use a new .md file (for example, WEBSITE-README.md) which is housed in the source code of the Resource on gem5-resources, and display that file, if it exists, on the website. If it does not, we will display the "description" field.

gem 5 statistics problem

hi, please help me
-I uploaded the latest version of gem5 in gihub, I executed the following command (./build/X86/gem5.opt configs/example/fs.py --kernel=/media/ali/ali/gem5/full_system/binaries/x86_64-vmlinux-2.6.22.9.smp)with disk image x86root-parsec.img.
i used a .rcs script to run a parsec application eg blackscholes, when i saw the stats file .txt i found several parts of (begin simulation ............ ..and simulation) with deferent information for example the execution time; because I think that in reality I found one part of (begin simulation .... end simulation)
to take the correct execution time .
thank you;

AMD APU gem5 simulator with HSA support

I am trying to build AMD APU simulator which supports Heterogeneous System Architecture (HSA) with internal graphics but to full system configuration of such system to build gem5 simulator is not known to me.
All that I got is http://www.gem5.org/GPU_Models which contains some tutorial for AMD APU but I would like to use any prebuild full system APU simulator, if available.
Kindly help me on this.

RVV (v.1.0) Support in Gem5

Does Gem5 support RVV32 (v. 1.0)?

"end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)" on fs_bigLITTLE.py

I've been asked by email:

./build/ARM/gem5.opt configs/example/arm/fs_bigLITTLE.py --caches --kernel=/media/ali/ali/gem5/linux-arm64-gem5-gem5/vmlinux --dtb=/media/ali/ali/gem5/system/arm/dt/armv8_gem5_v1_big_little_2_2.dtb --disk=/media/ali/ali/gem5/fs_armv8/disks/aarch64-ubuntu-trusty-headless.img --bootscript=/media/ali/ali/gem5/system/arm/aarch64_bootloader/boot_emm.arm64

failed with:

end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Error when tracing is off causes failure

The gem5 error. Should be a simple fix to import fatal

NameError: name 'fatal' is not defined

At:
  ../../src/gem5/python/m5/main.py(343): _check_tracing
  ../../src/gem5/python/m5/main.py(528): main

Gem5 simulation speed too slow

Hi, I`m running ubuntu server on gem5 now, and the simulation speed is too slow that it takes couple minutes to complete only one command. Is that normal?

Running gem5 : scons build/x86/gem5.opt config/example/fs.py --kernel=vmlinux --disk-image=x86.img --mem-size=8G

I`ve checked cpu type in config.ini under m5out/, and shows type=AtomicSimpleCPU.

Does anyone know how to speed up gem5 simulation?

gem5 to Streamline apc file has error

Describe the bug
util/streamline/m5stats2streamline.py script produced .apc file is invalid
--> in newer DS-5 streamline (29rel1), ultimate edition --> invalid apc format
--> in older DS-5 streamline (24rel1), ultimate edition --> error is,
Error detected in the binary data with respect to end-of-line markers. Check the settings on any FTP tools used and ensure any ASCII end-of-line conversions are disabled.
java.io.IOException: Error detected in the binary data with respect to end-of-line markers. Check the settings on any FTP tools used and ensure any ASCII end-of-line conversions are disabled.
at com.arm.streamline.analysis.gator.GatorProtocolV17.processSummary(GatorProtocolV17.java:107)
at com.arm.streamline.analysis.gator.GatorProtocolV17.process(GatorProtocolV17.java:62)
at com.arm.streamline.analysis.gator.GatorDatabase.processOnce(GatorDatabase.java:127)
at com.arm.streamline.analysis.gator.GatorDatabase.processOnce(GatorDatabase.java:137)
at com.arm.streamline.analysis.gator.GatorDatabase.process(GatorDatabase.java:145)
at com.arm.streamline.analysis.AnalysisBase.run(AnalysisBase.java:59)
at java.lang.Thread.run(Thread.java:745)

Affects version
v22.1, v23.0

gem5 Modifications
The modification done mainly in the util/streamline/m5stats2streamline.py .

1. in the function,

def string_to_int(string): #added function
  try:
    return int(string)
  except ValueError:
    return None

############################################################
# Write binary
############################################################
def writeBinary(outfile, binary_list):
    for i in binary_list: #added line
        if isinstance(i,str): #added line
            i_temp = string_to_int(i) #added line
            if (i_temp == None): #added line
                i = i #added line
            else: #added line
                i=i_temp #added line
        if isinstance(i,int): #added line
            i = chr(i) #added line
        byteVal = bytes(i, "utf-8") #added line
        #outfile.write(f"{i:c}") # original line
        outfile.write(byteVal) #added line

I see that in binary_list provided to writeBinary sometimes has combination of int and strings! . so just outfile.write(f"{i:c}") gives type error that byte like object need and not str.

2. packed32(x) function, where x has to be int and sometimes its not int and its float!

def packed32(x):
    ret = []
    more = True
    while more:
        x =int(x) #added line
        b = x & 0x7F
        x = x >> 7
        if ((x == 0) and ((b & 0x40) == 0)) or (
            (x == -1) and ((b & 0x40) != 0)
        ):
            more = False
        else:
            b = b | 0x80
        ret.append(b)
    return ret

Expected behavior
Expected behavior is to see the waveform in arm DS-5 streamline for gem5 FS of arm-linux. I have the license for older streamline version that could be compatible with gem5 conversion script.

Host Operating System
Ubuntu 18.04

Host ISA
x864

Reproduce
I have enabled context switch dump. I attached the files,

python m5stats2streamline.py ./stat_config.ini ./streamline ./streamline.apc
zip -r ./streamline.apc.zip ./streamline.apc (then import the apc.zip file in DS-5 streamline)

"ImportError: No module named common" in MI_example.py

$ build/X86/gem5.opt configs/ruby/MI_example.py

output : gem5 Simulator System. http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 compiled Oct 9 2017 06:22:48
gem5 started Oct 9 2017 06:31:28
gem5 executing on amb, pid 2503
command line: build/X86/gem5.opt configs/ruby/MI_example.py

Traceback (most recent call last):
File "", line 1, in
File "/home/amb/gem5/src/python/m5/main.py", line 433, in main
exec filecode in scope
File "configs/ruby/MI_example.py", line 34, in
from Ruby import create_topology, create_directories
File "configs/ruby/Ruby.py", line 48, in
from common import MemConfig
ImportError: No module named common

How to fix this?

xx86root-parsec.img image with the kernel x86_64-vmlinux-2.6.28.4-smp problem

hi,please help me ,I have a problem, when I executed the x86root-parsec.img image with the kernel x86_64-vmlinux-2.6.28.4-smp I find this:
] stop_this_cpu+0x0/0x30
[] smp_call_function_mask+0x1de/0x250
[] vsnprintf+0x268/0x6b0
[] printk+0x40/0x45
[] native_smp_send_stop+0x20/0x30
[] panic+0x82/0x129
[] do_exit+0x7de/0x890
[] printk+0x40/0x45
[] oops_end+0x7a/0xc0
[] do_invalid_op+0x84/0xa0
[] xsave_cntxt_init+0x35/0x130
[] release_console_sem+0x1ae/0x200
[] up+0xd/0x40
[] error_exit+0x0/0x51
[] xsave_cntxt_init+0x35/0x130
[] xsave_cntxt_init+0x35/0x130
[] fpu_init+0x4a/0x97
[] cpu_init+0x319/0x33f
[] start_kernel+0x1b2/0x321
[] x86_64_start_kernel+0xd9/0xdd
---[ end trace 4eaa2a86a8e2da22 ]---

Daily GPU tests fail to output the random seed used

As mentioned in pull request #131 , the workflow for dailies needs to be altered so that the random seed used for tests is output in order to allow for us to recreate tests. More specifics copied from the PR below:

"This test is using a random time-based seed and the tester does not print out what the value is. This could make it very difficult in the future to reproduce the test. It happens to be fine here as every seed will fail for sure. The protocol tester should print out what the seed is or the github action command should explicitly add --random-seed=."

`BaseCache::recvTimingResp` can trigger an assertion error from `getTarget()` due to MSHR in `senderState` having no targets

This was identified by Eliot moss on our gem5-users mailing list (https://www.mail-archive.com/[email protected]/msg21771.html). Copy and pasted verbatim:

Dear gem5-ers -

I've run across something, which unfortunately I cannot reliably repeat, that
suggests an oversight in the code of src/mem/cache/base.cc.  In particular, it
appears that a HardPFResp can arrive where the MSHR remembered in the packet's
senderState no longer has any targets.  This causes this line to fail with an
assertion error in getTarget():

const QueueEntry::Target *initial_tgt = mshr->getTarget();

Presumably some suitable conditionalization on mshr->hasTargets() could be
used to fix things, unless the problem is that somehow the target(s)
disappeared when they should not have.  My suspicion is that something to do
with snooping by another cache caused the target to go away, and the situation
should just be ignored, but I did not want to attempt a fix along the lines of
testing hasTargets() without further confirmation.  There is also the question
of what to do about the stats in this case, there being no obvious basis for
determining a latency.  [We could change the senderState to include the time
the prefetch began, though, and use HardPFReq as the command.]

Regards - Eliot Moss

The const QueueEntry::Target *initial_tgt = mshr->getTarget(); line mentioned in the email refers to:

gem5/src/mem/cache/base.cc

Line 528 in af72b9b

const QueueEntry::Target *initial_tgt = mshr->getTarget();

Adding VLEN and ELEN dynamic configuration to RISCV V 1.0 implementation

Hi!
I want to ask if someone is working on the dynamic configuration of ELEN and VLEN constant parameters in the RISCV Vector path. At this moment, if experimenting with different values of these parameters is needed, it is mandatory to recompile gem5 each time.

I have been working on and testing a possible implementation during the last weeks. So, I could work together on this task if you agree with that.

Also, during my testing, I found some erroneous behaviours in specific instructions (i.e. vle instructions) when using a large enough VLEN value, generally above or equal to 2^14. This can be related to the microVl selected data type for implementing these instructions, although I am not 100% sure yet.

I am also tagging Adrià since he is supervising the effort we are carrying out with RISCV Vector in our group and he could be interested in reviewing this thread in the future. @adriaarmejach

Enable loading of local gem5 Resources data by a simple passing of the data's JSON file path

As of v23.0 the user can specify custom gem5 Resources data locations (i.e., JSON files or database which store the gem5-resources meta-data: IDs, source information, download links, etc.) by creating a configuration file named "gem5-config.json" in the CWD or by using the GEM5_CONFIG environment variable to specify the location of the config. If neither a "gem5-config.json" file is present in the CWD or the GEM5_CONFIG environment variable is unset, the "src/python/gem5_default_config.py" defaults are used (our MongoDB instance).

The reason a configuration file is needed is because gem5, as of v23.0, supports resource data being stored in a JSON file or in a MongoDB database. v23.0 also allows for multiple data sources to be merged, so users may, for example, use the gem5 project's MongoDB database as well as a local JSON file. In this case the configuration would look something like:

{
    "sources": {
        "gem5-resources-local-json": {
            "url": "<path to resources.json>",
            "isMongo": false
        },
        "gem5-resources": {
            "dataSource": "gem5-vision",
            "database": "gem5-vision",
            "collection": "resources",
            "url": "https://data.mongodb-api.com/app/data-ejhjf/endpoint/data/v1",
            "authUrl": "https://realm.mongodb.com/api/client/v2.0/app/data-ejhjf/auth/providers/api-key/login",
            "apiKey": "OIi5bAP7xxIGK782t8ZoiD2BkBGEzMdX3upChf9zdCxHSnMoiTnjI22Yw5kOSgy9",
            "isMongo": true,
        }
    }
}

This is an ok solution for the criteria of handling two different resources data source types and specifying multiple locations to be used in unison . However, the downside of this new approach is it requires creation of the configuration file every time the user wishes to use resources other than those specified in the project's MongoDB instance. I've found that 9 times out of 10 if I have a local gem5 Resources data i want to be loaded into gem5 then it's in the JSON format and I'm not interested in loading other sources. Prior to gem5 v23.0 users could specify a local resource JSON file to load using the GEM5_RESOURCE_JSON environment variable, but in v23.0 this was removed in favor of the configuration file.

I think given passing a single resources JSON file is so common, there should be an simple way to do it which doesn't require creation of a configuration file. The user should only need to pass the path to the JSON file.

I can think of two solutions for this problem:

1. Re-implement the GEM5_RESOURCE_JSON environment variable and, if set, the gem5 standard library uses it's value as the path to load the resources JSON from alone, ignoring all other data sources. (Perhaps there should also be another environment variable (GEM5_RESOURCE_JSON_APPEND?) which appends the resources JSON file to the default MongoDB database. This could also be useful).
2. Add a parameter to the obtain_resources function which enables the passing of a file path to a resources JSON file. If set, this local JSON file would be used (note: work would need done to ensure this doesn't interference with the clients parameter in this function).