> On Dec 2, 2014, at 3:17 PM, Mario Zechner wrote:
>
> Sorry, i should glue the "Reply All" button. Expanding a little bit on the
> original message...
>
> For issue one, an alternative solution would be to set multiple breakpoints
> if we find an IT in the current range. One for every branch
Sorry, i should glue the "Reply All" button. Expanding a little bit on the
original message...
For issue one, an alternative solution would be to set multiple breakpoints
if we find an IT in the current range. One for every branch instruction
within the IT block. If there are no branch instruction
So there's two issues here. The more crucial one is how do we step over the IT
& the instructions it governs. Seems to me the answer to that - provided we
can figure out that we are in this situation - is to temporarily turn off
fast-stepping here.
The other issue is how would we set a breakp
I was just about writing up such an example as your new messages came in. I
also wonder: would the trap get executed at all if the condition is not
meet? From what i saw when testing things, the CPU seems to have skipped
the trap (because the condition wasn't meet) and then tried to execute the
nex
Again, this is a good analysis of why we are crashing. But it isn't the right
solution for stepping. When we are stepping through the IT & the instructions
it governs we need to make sure we DON'T try to do the fast-stepping, but just
use the hardware single step and go instruction by instruct
We talked about this a little more, and though in general correctly using a 32
bit thumb breakpoint is a good idea, it doesn't solve the problem with stepping
vrs. the IT instruction. First off, since we don't actually know where the IT
instruction is going to go, for stepping purposes it is ef
So the nitty gritty details are IT is followed by up to four "i" for if, or
"e" for else.
So if you have:
IT ieei
op1 (if)
op2 (else)
op3 (else)
op4 (if)
The if/else bits are stored in the CPSR so it knows that an IT is going on and
the condition is stored in some bits and the if/else b
I guess the 4-byte instruction could be replaced by a 2-byte trap and a
2-byte nop (if that exists on ARM). Or any 2-byte instruction instead of
the nop. If i understand correctly, once the trap is hit, the original
4-byte instruction should be restored again, no? If that's not the case, i
could ma
The problem here is that we are modifying a 32 bit instruction with a 16 bit
trap. The "IT" instruction isn't a branch and it shouldn't be considered one.
The solution of using a 4 byte thumb breakpoint must be used and this will work
for Linux, but won't work on MacOSX because our kernel, to my
As I read the whole post I realized this probably isn't your issue. But please
do make sure that your symbols are marked correctly.
> On Dec 2, 2014, at 1:46 PM, Greg Clayton wrote:
>
> Your functions in the symbol table must be correctly marked as "thumb"
> functions and they probably aren't
Your functions in the symbol table must be correctly marked as "thumb"
functions and they probably aren't.
To mark a function as thumb, you must set the "n_desc" field of all thumb
functions to be "0x0008".
Looking at a dump from "dsymutil -s" on a Master Detail template app built for
armv7:
It does indeed feel ugly. My current fix checks the arch and opcode within
ThreadPlanStepRange in case the LLVM based disassembler tells us that the
instruction is not branching. This pulls arch specific code into the thread
plan which feels all kinds of wrong. I could try pushing it down further
w
The question that the stepping code is really asking is "can I predict the next
instruction that will follow on from this one before I get there." If IsBranch
isn't sufficient to know that for some instruction or class of instructions,
then adding whatever other tests are required seems okay fo
Sorry Stephane, forgot to hit "Reply all".
I dug a bit deeper. The problem is in LLVM's instruction table for ARM
Thumbv2. Here's the definition of the IT instruction (llvm/lib/Target/ARM/
ARMInstrThumb2.td):
// IT block
let Defs = [ITSTATE] in
def t2IT : Thumb2XI<(outs), (ins it_pred:$cc, it_mas
I suppose it wouldn’t get hit, no. I don’t know about considering it
instructions as a branching instruction. I guess it makes sense but I don’t
know how the rest would work with it.
--
Stephane Sezer
> On Dec 1, 2014, at 10:47 AM, Mario Zechner wrote:
>
> Thanks, i'm going to try that. I ju
Thanks, i'm going to try that. I just wonder if it would make more sense to
consider the it instruction a branching instruction. Not sure what side
effects that may have.
Also, if i wrote a 4-byte breakpoint for blne, would it get hit if the it
branches over it? Guess i'll find out :)
On Dec 1, 20
I remember fighting with this recently in our debug server (ds2), your
understanding of the problem is correct I believe. What you need to do is to
place a four-byte thumb breakpoint instead of a two-byte thumb breakpoint. I
don’t know what the iOS kernel expects exactly, but for example the Lin
I think i understand the issue now.
ThreadPlanStepRange::SetNextBranchBreakpoint
is falsely selecting the blne instruction instead of the it instruction.
The condition is not meet, so the CPU jumps over the instruction after it.
Since we have a trap there that's 2 bytes long, it will end up at 0x27
I traced through ThreadPlanStepRange and ThreadPlanStepRange for this piece
of code:
0x27b2d4 <[J]java.lang.Object.()V>: push {r7, lr}
0x27b2d6 <[J]java.lang.Object.()V+2>: movr7, sp
0x27b2d8 <[J]java.lang.Object.()V+4>: subsp, #0x4
0x27b2da <[J]java.lang.Object.()V+6>: movs r2, #0x
Well, i wrote a very long mail detailing my journey to resolve issue #2
(hanging after setting target.use-fast-stepping=false), only to eventually
realize that it doesn't hang but instead just waits for the above loop to
complete.
This means turning off target.use-fast-stepping is not an option an
Hi,
setting target.use-fast-stepping to false did indeed solve this issue,
albeit at the cost of increased runtime obviously. However, i ran into
another issue right after i stepped out of the previously problematic
function: http://sht.tl/bdAKRC
Trying to source-level step this function (with us
The size of the breakpoint instruction is set by
GetSoftwareBreakpointTrapOpcode(). In your case, most likely you're in
PlatformDarwin::GetSoftwareBreakpointTrapOpcode() - lldb uses the symbol table
(from the binary file) to determine if the code in a given function is arm or
thumb. If it's a
I dug a little deeper, inspecting the GDB remote packets send by LLDB to
perform the stepping. It appears when sending memory breakpoint commands
used for stepping, the size of the instruction being replaced isn't taken
into account, or writing back the original instruction isn't done properly.
The
Hi,
we generate thumbv7 binaries for iOS devices. We deploy, launch and debug
those via LLDB. Stepping into functions seems to almost always generate a
EXC_BAD_INSTRUCTION signal. The signal is not generated when running the
app without the debugger attached. It is also not generated when we attac
24 matches
Mail list logo
