If no one has any better ideas, I'd try to use GDB on the gem5
executable itself, turn on ExecAll logging, and break on the stat dump
part of the code and see where both calls come from. Also consider
Mozilla rr reverse debugging if it seems that reverse stepping could
help. Not ideal, but works e
Thanks for your response.
Double checked. There doesn't seem to be a problem with the executable.
attached are the disassembly of the ROI begin and end functions and the
original code.
I have debugged with GDB and stepped over the m5 commands, they occur only
once and in the correct sequence.
all
Can you double check with aarch64-linux-gnu-objdump that the binary
really only contains a single pseudoop? Maybe it is just an
instrumentation bug that doubles it up.
I would also recommend that you try to correlate --debug-flags ExecAll
or GDB the guest executable around the pseudoop point to na
