= gem5 issues :idprefix: :idseparator: - :sectanchors: :sectlinks: :sectnumlevels: 6 :sectnums: :toc: macro :toclevels: 6 :toc-title:
gem5 issue tracker, HOWTOs, FAQs, and architecture overview.
toc::[]
== About
This repository has two functions:
=== Issue tracker
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.
=== Cheatsheet
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.
== How does gem5 find its Python configuration imports?
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('../') ....
== How to specify the bootloader explicitly without M5_PATH in fs.py?
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.
== How to build gem5 with ccache?
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 ....
== Source code analysis
=== Why everything under src/python requires a rebuild even though it is Python?
=== What is the structure of the build directory?
At a5bc2291391b0497fdc60fdc960e07bcecebfb8f we have:
.scons_config/
ARM/
drampower/
dramsim2/
fputils/
googletest/
iostream3/
libelf/
libfdt/
nomali/
systemc/
variables/
scons_config.log
sconsign.dblite
variables.globalSo basically:
ARM/: contains src/ build objects and symlinks to sourcevariables/ARM and variables.global: SCons Variables thingy: https://scons.org/doc/2.4.1/HTML/scons-user.html#idp1378575484scons.*: SCons metadata, don't askext/. Therefore presumably arch agnostic and reused across builds of different archs.== ISA tutorial
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.
== ARM
=== Where is the ARM ISA decode entry point?
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
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:
....
....
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?
=== How are the arm disk images generated?
TODO
The ones present at http://www.gem5.org/dist/current/arm/ with filenames of type:
arm-system-YYYY-MM.tar.xzaarch-system-YYYY-MM.tar.xzI want to know what they contain in detail, and how to modify them.
=== How to view and modify DTBs?
Best approach: we have automatic DTB generation as of 49f96e7b77925837aa5bc84d4c3453ab5f07408e:
fs.py: --generate-dtb, but there is a bug: https://github.com/cirosantilli-work/gem5-issues/issues/18fs_bigLITTLE.py: if you don't pass --dtb, auto-generation is used automaticallyDirect 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.dtssystem/arm/dt/Makefileso you can just hack them up and rebuild.
Related: https://www.mail-archive.com/gem5-users@gem5.org/msg15636.html