Hi Tobias,
If memory serves, only direct control instructions have branch targets because the target information is encoded in the instruction. Indirect control targets don't because the instruction itself is insufficient to provide a target; it requires reading a register and branching to the address encoded in the register. B and Bl are both direct control instructions while bx is indirect. Ali On 04.10.2012 22:25, Tobias Friemel wrote: > I have got some progress. It seems like the function "StaticInstPtr decode(ArmISA::PCState &nextPC)" is the only decode function that returns the right StaticInst. Things like setting the isMisc bit in the ExtMachInst seems to be crucial before decoding. > > But I'm stuck with the next problem. Now, hopefully with the right StaticInst, I'm calling hasBranchTarget and the check for indirect controll passes. Then the default StaticInst::branchTarget function is called which panics with the message "StaticInst::branchTarget() called on instruction that is not an indirect branch." In comparison for a normal branch instruction (just b) the function B::branchTarget in arm/arch/generated/decoder.cc is called. I found a similar function for Bl, but not for Bx. Can it be that there is missing something? > > Regards, > Tobias > > Am 02.10.2012 22:19, schrieb Tobias Friemel: > >> 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 [2] 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: %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 [1] >>>>>>> >>>>>>> _______________________________________________ >>>>>>> gem5-users mailing list >>>>>>> gem5-users@gem5.org >>>>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [1] >>>>> >>>>> _______________________________________________ >>>>> gem5-users mailing list >>>>> gem5-users@gem5.org >>>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [1] >>> >>> _______________________________________________ >>> gem5-users mailing list >>> gem5-users@gem5.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [1] >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [1] > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [1] Links: ------ [1] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [2] http://grok.gem5.org/source/xref/gem5/src/cpu/exetrace.cc#108
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
