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: %sn", 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 >>>>> 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
