I honestly wouldn't know where to start. The wrong branch instructions
were created by an embedded forth compiler. I just tried mem-copying a
single definition containing one of those erroneous branches to some ram
array and then call into it with a pointer. The problem is that the
definition assum
There might still be some issues...
Single-stepping works as long as I don't let GDB display the assembly
with "display/i $pc". Once GDB decodes and displays every instruction
the debugging session gets canceled when I hit the unpredictable branch.
I'm not sure if this has anything to do with QEMU
Jesus... I'm sorry about the delay. Eclipse kept dying on me when
launching gdb so I had to first set up another IDE since I really really
didn't want to single-step through with the command line.
Anyhow. The behavior of QEMU during debugging is now identical to the
one when running it. Even with
Oh damn it, you're right. Apparently encoding T3 of the branch
instruction inside an IT block is always unpredictable... Guess the
inline assembly version ignores the .w extension and creates some other
encoding that simply works.
I've attached the .elf which is causing GDB to halt.
Currently I'm
Public bug reported:
Hello
There seems to be an issue with QEMU when debugging if-then condition
blocks from the thumb2 instruction set. The following snippet runs fine
during normal execution, but keeps hanging at the conditional branch
when debugging. The jump at the branch should only be execu
