Elastic Trace Probe Type-Mismatch Panic in O3CPU

[sjain70]

I am facing Panic in probe.hh: Wrong type of listener expected for ElasticTrace in O3CPU (ARM)

The simulation panics at tick 0 during the registration of probe listeners. The ElasticTrace probe attempts to attach to the Commit probe point of the O3CPU, but there is a C++ template type mismatch between the pointer type provided by the probe point and the type expected by the ElasticTrace listener.

Environment:
Gem5 version: v25.0.0.1-0-gddd4ae35ad

Steps to Reproduce:
bash
build/ARM/gem5.opt configs/example/arm/etrace_se.py
--cmd=tests/test-progs/hello/bin/arm/linux/hello
--inst-trace-file fetchtrace.proto.gz
--data-trace-file deptrace.proto.gz

Observed Error (Backtrace):
src/sim/probe/probe.hh:300: panic: panic condition !l occurred: Wrong type of listener:
expected N4gem520ProbeListenerArgBaseINS_14RefCountingPtrINS_2o37DynInstEEEEE
got N4gem516ProbeListenerArgINS_2o312ElasticTraceENS_14RefCountingPtrIKNS1_7DynInstEEEEE

The Expected Type: gem5::RefCountingPtrgem5::o3::DynInst (Non-const pointer)
The Provided Type: gem5::RefCountingPtr (Note the IK in the mangled name, indicating const)
Root Cause: The O3CPU probe point in src/cpu/o3/commit.cc was likely updated to pass a non-const pointer, but the ElasticTrace listener in src/cpu/o3/probe/elastic_trace.hh still expects a const pointer (or vice versa), causing the dynamic_cast in the probe system to fail.

Expected Fix:
Update src/cpu/o3/probe/elastic_trace.hh and .cc to ensure the ProbeListenerArg signature matches the DynInst pointer const-ness expected by the O3CPU commit probe.

Please let me know where to find the fix/ how to resolve the issue?

[yangguoming]

I also meet this error, did you figure out it?

[dane73]

I have also encountered this error. As far as I can tell, it’s connected to commits d315ca5 and e693c4f.

The latest version that does not include these two commits is v24.1.0.3, which I am currently using as a workaround. The only issue I found is that the build system is broken on Fedora, but this can be fixed by cherry-picking commit de3376b from #2080.

The example config works as expected, though I’m not sure how other parts of the system are affected by the downgrade.