Inst and si->machInst are both saying 12fff13.
Running with debug flag ExecAll prints bxeq. So I tried printing the
machInst at
http://grok.gem5.org/source/xref/gem5/src/cpu/exetrace.cc#108 and it's
showing 1012FFF13. I'm not sure why there is a difference and if it's
matters.
Regards,
Tobias
Am 02.10.2012 19:28, schrieb Ali Saidi:
Hi Tobias,
I still don't see how that instruction could be decoded as a teq. I've
executed it a couple of times with text programs and it's always
decoded as a bxeq in the Exec trace output.
Assuming you're instrumenting the code is setSingleStep) could you
print out the inst and the si->machInst that are there? inst should be
the same as what you've printed below and machInst has some bits
pre-decoded that could be the problem, but I don't see how the
simulator could be in a state where those are wrong.
Ali
On 02.10.2012 09:41, Tobias Friemel wrote:
From the objdump output it's "012fff13 bxeq r3".
And I used this code to get the instruction and print the decoded
version:
MachInst inst;
FSTranslatingPortProxy &proxy = tc->getVirtProxy();
proxy.readBlob(pc.pc(), (uint8_t*)&inst, sizeof(MachInst));
StaticInstPtr si = tc->getDecoderPtr()->decode(inst, pc.pc());
DPRINTF(Fail, "Instr: %s\n", si->disassemble(pc.pc()).c_str());
Regards,
Tobias
Am 02.10.2012 16:34, schrieb Ali Saidi:
Hi Tobias,
I don't think it's possible that bxeq is a teqeq. The TEQ
instruction doesn't write any destination registers including the
PC, so I'm not sure how it could cause a branch.
Could you print out the bits of the machine instruction that you're
having a problem with?
Thanks,
Ali
On 02.10.2012 09:19, Tobias Friemel wrote:
I have tested both versions, the stable and the development
branch. The problem with the "bxeq r3" instruction is that it
gets decoded to "teqeq pc, r3, LSL pc" which seems to do the
same, but doesn't get marked as a control transfer instruction.
I'm still missing an idea for a workaround to this.
Regards,
Tobias
Am 20.09.2012 18:09, schrieb Ali Saidi:
The setSingleStep code isn't particularly robust, but you
should be able to address the issues that you've described
here. You can check if the instruction is a 32bit thumb
instruction by looking at the ExtMachInst and adjust it
appropriately. I don't know what version of the simulator
you're using, but we fixed some identification of branch
instructions recently. THat said I'm very surprised that
bxeq isn't recognized as it certainly should be.
Ali
On 20.09.2012 11:03, Tobias Friemel wrote:
Hello,
I'm working on a thesis that includes fault injection in connection
with
gem5 (ARM specific) and I'm looking for a way to implement some
sort of
single stepping for this. I already found the method the RemoteGDB
uses,
but there seems to be a problem with some machine instructions.
What the RemoteGDB does, is looking at the current program counter
and
setting a new breakpoint to the next PC. If the instruction at the
current PC is a branch, it also sets a new breakpoint to the branch
target. The first problem I found was that the bxeq instruction
(like
the one that is in the example bootloader for arm) isn't recognized
as a
branch instruction. Another problem is that for Thumb-2
instructions,
the next PC is always set to 16 bit after the current, even if it's
a 32
bit long instruction.
Maybe someone knows an easy way to fix this or if there is a better
way
to get single stepping.
Regards,
Tobias
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org <mailto:gem5-users@gem5.org>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
