gem5 issue tracker, HOWTOs, FAQs, and architecture overview.
This repository has two functions:
-
be an Issue tracker for gem5
-
contain a Cheatsheet of how to do common stuff in gem5
Edit: one was created in 2020 at: https://gem5.atlassian.net/projects/GEM5/issues
Old section:
Completely unofficial gem5 issue tracker for https://github.com/gem5/gem5 , the mailing list is the only official one: http://gem5.org/Mailing_Lists Request for official GitHub tracker was declined:
go ping the mailing list thread if you want it.
Maintained on a best effort basis, I will try to label, reproduce and close bugs reported.
Anyone is welcome to open bugs here, but they will likely not be seen by any devs except me.
For usage questions, prefer the Stack Overflow gem5 tag: https://stackoverflow.com/questions/tagged/gem5 although it will also likely not be seen by the other main devs currently either.
Double posting here in addition to the official tracker is encouraged.
Linux kernel related things and some more will be kept at: https://github.com/cirosantilli/linux-kernel-module-cheat#gem5 only baremetal, internals and other Linux-agnostic stuff will be documented here.
These cheats will often be summaries of solved issues, or smaller things which we didn’t think deserve an issue, or that we were able to solve by ourselves without creating an issue.
I think it is just done with PYTHONPATH
, nothing is hardcoded on the executable.
However, many of the scripts add stuff to the PYTHONPATH
, so that you can just point to them, and they will import the relative files automatically.
E.g. fs.py
contains https://github.com/gem5/gem5/blob/49f96e7b77925837aa5bc84d4c3453ab5f07408e/configs/example/fs.py#L55:
addToPath('../')
Edit: a param --bootloader
parameter was added to fs.py and se.py for that: https://stackoverflow.com/questions/56319473/gem-5-ioerror-cant-find-a-path-to-system-files-full-system-x86-simulation-set/56320982#56320982
I just want to point to boot_emm.arm
directly, and not have it be found with the annoying environment M5_OUT
variable.
Does not seem possible as of 49f96e7b77925837aa5bc84d4c3453ab5f07408e.
CXX='ccache c'` does not work, `CXX=/my/path/to/ccache/wrapper/c
does not work, the only thing that works it to put c++
it in your PATH
as a ccache gem5 symlink:
export PATH="/usr/lib/ccache:${PATH}" scons
At a5bc2291391b0497fdc60fdc960e07bcecebfb8f we have:
.scons_config/ ARM/ drampower/ dramsim2/ fputils/ googletest/ iostream3/ libelf/ libfdt/ nomali/ systemc/ variables/ scons_config.log sconsign.dblite variables.global
So basically:
-
ARM/
: containssrc/
build objects and symlinks to source -
variables/ARM
andvariables.global
: SConsVariables
thingy: https://scons.org/doc/2.4.1/HTML/scons-user.html#idp1378575484 -
scons.*
: SCons metadata, don’t ask -
all other directories: from
ext/
. Therefore presumably arch agnostic and reused across builds of different archs.
The ISA is a funky Python mini-language that generates C++ code.
It exists partly because gem5 dates from 2003, when C templates were not good enough, but also because it is inherently complex to map registers across multiple CPU models. C will likely reduce the need for this madness.
Sample backtrace into the decoder entrypoint:
ArmISA::Decoder::decodeInst (this=this@entry=0x4b0a0a0, machInst=machInst@entry=...) at /out/gem5/master/opt/build/ARM/arch/arm/generated/decode-method.cc.inc:8 GenericISA::BasicDecodeCache::decode (this=this@entry=0x2eebd20 <ArmISA::Decoder::defaultCache>, decoder=decoder@entry=0x4b0a0a0, mach_inst=..., addr=<optimized out>) at /out/gem5/master/opt/build/ARM/arch/generic/decode_cache.cc:55 ArmISA::Decoder::decode (addr=<optimized out>, mach_inst=..., this=<optimized out>) at /out/gem5/master/opt/build/ARM/arch/arm/decoder.hh:175 ArmISA::Decoder::decode (this=this@entry=0x4b0a0a0, pc=...) at /out/gem5/master/opt/build/ARM/arch/arm/decoder.cc:194 BaseSimpleCPU::preExecute (this=this@entry=0x4709700) at /out/gem5/master/opt/build/ARM/cpu/simple/base.cc:528 AtomicSimpleCPU::tick (this=0x4709700) at /out/gem5/master/opt/build/ARM/cpu/simple/atomic.cc:673 std::function<void ()>::operator()() const (this=0x4709a48) at /usr/include/c++/6/functional:2127 EventFunctionWrapper::process (this=0x4709a10) at /out/gem5/master/opt/build/ARM/sim/eventq.hh:836 EventQueue::serviceOne (this=this@entry=0x3b7fea0) at /out/gem5/master/opt/build/ARM/sim/eventq.cc:228 doSimLoop (eventq=0x3b7fea0) at /out/gem5/master/opt/build/ARM/sim/simulate.cc:219 simulate (num_cycles=<optimized out>) at /out/gem5/master/opt/build/ARM/sim/simulate.cc:132
where is the main generated decoder file: /out/gem5/master/opt/build/ARM/arch/arm/generated/decode-method.cc.inc
.
Some of the constants are then defined at:
src/arch/arm/isa/bitfields.isa
e.g.:
def bitfield THUMB thumb; def bitfield BIGTHUMB bigThumb; def bitfield AARCH64 aarch64;
which are in turn defined at:
src/arch/arm/types.hh
as:
BitUnion64(ExtMachInst) Bitfield<36> thumb; Bitfield<35> bigThumb; Bitfield<34> aarch64;
the generated code then contains:
StaticInstPtr ArmISA::Decoder::decodeInst(ArmISA::ExtMachInst machInst) { switch (AARCH64) { case 0x0:
and grepping inside the autogenerated code we see:
#undef AARCH64 #define AARCH64 machInst.aarch64
Disassembly then confirms that it is testing bit 34. TODO: arm instructions are only 4 bytes long, so where do those extended bytes come from?
TODO
The ones present at http://www.gem5.org/dist/current/arm/ with filenames of type:
-
arm-system-YYYY-MM.tar.xz
-
aarch-system-YYYY-MM.tar.xz
I want to know what they contain in detail, and how to modify them.
Best approach: we have automatic DTB generation as of 49f96e7b77925837aa5bc84d4c3453ab5f07408e:
-
fs.py
:--generate-dtb
, but there is a bug: #18 -
fs_bigLITTLE.py
: if you don’t pass--dtb
, auto-generation is used automatically
Direct approach: https://stackoverflow.com/questions/14000736/tool-to-visualize-the-device-tree-file-dtb-used-by-the-linux-kernel/39931834#39931834
Indirect: the DTBs are generated from dts files in-tree with Makefiles, e.g. in 49f96e7b77925837aa5bc84d4c3453ab5f07408e:
-
system/arm/dt/armv8_big_little.dts
-
system/arm/dt/Makefile
so you can just hack them up and rebuild.