IntSourcePin not bound with CXX config
When simulating the TLM full system setup example with x86
./../../../gem5_github/build/X86/gem5.opt ../../../gem5_github/configs/example/fs.py --kernel ../../../kernels/x86_kernel/x86_64-vmlinux-3.2.24 --disk-image ../../../kernels/x86_kernel/linux-bigswap2.img --cpu-type TimingSimpleCPU --mem-type DDR3_1600_8x8 --tlm-memory transactor
./build/examples/slave_port/gem5.sc m5out/config.ini -o 0
gem5 encounters a segmentation fault. GDB shows the following output:
Program received signal SIGSEGV, Segmentation fault.
X86ISA::Cmos::X86RTC::handleEvent (this=<optimized out>) at build/X86/dev/x86/cmos.cc:40
After some investigations it seems that the external TLM memory and the x86 address ranges do not work together properly.
Without the external TLM memory the system boots up.
Ubuntu 20.04 LTS
You can simulate the TLM slave example in util/tlm with x86 ISA. The library has to be build using the additional USE_SYSTEMC=False option. Then change the ISA in the SConstruct file to ‘X86’ and run scons. Now you can run an example simulation as described in run_gem5_fs.sh. For x86 the address offset should be set to 0 (./build/examples/slave_port/gem5.sc m5out/config.ini -o 0). If you like you can also remove the coupled TLM memory and run a normal gem5 simulation with CXX config using the SystemC kernel.
Hmm… What’s the easiest way for us to reproduce the problem? I tried writing that fix without any way to test it
I applied the changeset to the release-staging-v21-0 branch (where is fixed) but I get the following error message when running a simulation with CXX config:
”Config problem in sim object system.pc.south_bridge.io_apic: Can't find response port object:”
Great! , let me know if that changeset works for you. If it does, I’ll clean it up a bit (remove the checks as discussed and change the names of the ports).
Assuming it works, we will probably want to put it on staging and maybe backport to 20.1, if that’s useful to you
Yes. There’s also the less serious issue where it’s using requestor/responder names for things which won’t be true and will be misleading, but I think funcitonally that won’t matter that much. It’s just something to clean up in the longer term. There are other things with the cxx_config mechanism that aren’t quite right which would be good to fix longer term also, but I don’t want to get into that here.