On 1/3/2023 11:15 PM, Hoa Nguyen via gem5-users wrote:
I believe you can compile build/X86/gem5.debug to have all the symbols
available for debugging.
Yes, they are. I dont think that's the issue.
I'm not sure about the error, but generally, when debugging an instruction, I would try to find the
internal name of the instruction in gem5, and look at gem5/build/X86/arch/x86/arch/generated/ to
find the implementation of the instruction.
I can find all the implementation, decoding, etc.
Regarding the unimplemented initiateAcc error, there are a few places to look
at,
- You can take a breakpoint when that instruction is decoded and find gem5's internal name for that
instruction (e.g., MOV_M_R or MOV_R_M).
- You can find how that instruction is decoded in
gem5/build/X86/arch/x86/generated/decode-method.cc.inc. It's probably decoded into micro-op(s).
- gem5/src/arch/x86/isa/insts/general_purpose/data_transfer/move.py seems to have the micro codes
for move instructions.
- You can use that name to find the ::execute() function, as well as ::initiateAcc() function of the
micro-ops in gem5/build/X86/arch/x86/generated/exec-ns.cc.inc.
I know what they are *supposed* to be from the coding the macro and micro
ops. My point is that something seems to have gotten messed up along the
way. So, if I have a DynInstPtr (technically, a const DynInstPtr &) in hand
in gdb, how to I examine it? All I see in gdb is a struct with fields Tiscont
and data, i.e., the fields of a RefCountingPtr. How do I chase through the
RefCountingPtr<T> (for appropriate T) to see the actual T object and its
fields is my question.
A different question is this: Does a DynInst in DerivO3 correspond to a
micro-op and a StaticInst to a macro-op?
Thanks for your assistance ... Eliot
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
