gem5-users@gem5.org

The gem5 Users mailing list

View all threads

X86 ALU instructions do not print the result to the debug log

DB
David Bears
Tue, Dec 9, 2025 1:46 AM

Hello,

I've been trying to track down an issue whereby some X86 instructions
are not printing their result to the debug log. Rather, the log always
shows "D=0x0000000000000000" even when the result is not zero. It
appears that most ALU instructions are properly saving the result with
traceData->setData, but then certain instructions immediately
overwrite that saved result with various flag registers that are also
set by the same ALU instructions. An example of this is in the generated
code for AndFlagsBig::execute. (The non-Flags versions don't seem to
have the same issue, but they also don't set the flag registers at all.)

Unfortunately, I can't seem to figure out why the code is generated this
way in order to correct it. Is there some way to easily avoid
callingĀ traceData->setData for all the flag registers (and only call
it for the result register)? Or is it possible to reverse the order of
these registers so that the result register is written last instead of
first?

Thank you,
David

Hello, I've been trying to track down an issue whereby some X86 instructions are not printing their result to the debug log. Rather, the log always shows "D=0x0000000000000000" even when the result is not zero. It appears that most ALU instructions are properly saving the result with `traceData->setData`, but then certain instructions immediately overwrite that saved result with various flag registers that are also set by the same ALU instructions. An example of this is in the generated code for `AndFlagsBig::execute`. (The non-`Flags` versions don't seem to have the same issue, but they also don't set the flag registers at all.) Unfortunately, I can't seem to figure out why the code is generated this way in order to correct it. Is there some way to easily avoid callingĀ `traceData->setData` for all the flag registers (and only call it for the result register)? Or is it possible to reverse the order of these registers so that the result register is written last instead of first? Thank you, David