> ...cut
> 00103550 <cyg_io_lookup>:
> 103550: e1a0c00d mov ip, sp
> 103554: e92dd870 stmdb sp!, {r4, r5, r6, fp, ip, lr, pc}
> 103558: e59f20c0 ldr r2, [pc, #192] ; 103620
> <cyg_io_lookup+0xd0>
> 10355c: e59f30c0 ldr r3, [pc, #192] ; 103624
> <cyg_io_lookup+0xd4>
> 103560: e24cb004 sub fp, ip, #4 ; 0x4
> 103564: e24dd00c sub sp, sp, #12 ; 0xc
> 103568: e1520003 cmp r2, r3
> 10356c: e1a04000 mov r4, r0
> 103570: e1a06001 mov r6, r1
> 103574: e50b2024 str r2, [fp, -#36]
It is using [fp, -#36] as the variable t.
> 103578: 0a00000c beq 1035b0 <cyg_io_lookup+0x60>
> 10357c: e24b501c sub r5, fp, #28 ; 0x1c
> 103580: e5921000 ldr r1, [r2]
> 103584: e1a00004 mov r0, r4
> 103588: e1a02005 mov r2, r5
> 10358c: ebffffa9 bl 103438 <cyg_io_compare>
> 103590: e3500000 cmp r0, #0 ; 0x0
Is the return value from cyg_io_compare 0?
> 103594: 1a000007 bne 1035b8 <cyg_io_lookup+0x68>
Branch if it is not equal, ie it is true. This is the case we have
found /dev/tty. So we branch to 1035b8.
> 103598: e51b2024 ldr r2, [fp, -#36]
> 10359c: e59f3080 ldr r3, [pc, #128] ; 103624
> <cyg_io_lookup+0xd4>
> 1035a0: e282201c add r2, r2, #28 ; 0x1c
> 1035a4: e1520003 cmp r2, r3
> 1035a8: e50b2024 str r2, [fp, -#36]
> 1035ac: 1afffff3 bne 103580 <cyg_io_lookup+0x30>
> 1035b0: e3e00001 mvn r0, #1 ; 0x1
> 1035b4: e91ba870 ldmdb fp, {r4, r5, r6, fp, sp, pc}
So here we are inside the if (cyg_io_compare(name, t->name, &name_ptr)) {
> 1035b8: e51b2024 ldr r2, [fp, -#36]
r2 now has the value of t.
> 1035bc: e5920004 ldr r0, [r2, #4]
r0 is loaded with t->dep_name. You can see in devtab.h that dep_name
is the second entry in the structure, so #4 makes sense.
> 1035c0: e3500000 cmp r0, #0 ; 0x0
Is it 0?
> 1035c4: 050b0020 streq r0, [fp, -#32]
This is a conditional store. If the last comparison is true, ie
t->dep_name is 0, store r0, which following the logic is 0, in
[fp, -#32], which i'm guessing, but have not confirmed, is stunion.st.
> 1035c8: 1a00000e bne 103608 <cyg_io_lookup+0xb8>
Branch if not equal, ie t->dep_name was not 0. This is what we expect
to happen, so we jump to 103608.
> 1035cc: e5923010 ldr r3, [r2, #16]
> 1035d0: e3530000 cmp r3, #0 ; 0x0
> 1035d4: 1a000002 bne 1035e4 <cyg_io_lookup+0x94>
> 1035d8: e3a00000 mov r0, #0 ; 0x0
> 1035dc: e5862000 str r2, [r6]
> 1035e0: e91ba870 ldmdb fp, {r4, r5, r6, fp, sp, pc}
> 1035e4: e24b1020 sub r1, fp, #32 ; 0x20
> 1035e8: e8910006 ldmia r1, {r1, r2}
> 1035ec: e24b0024 sub r0, fp, #36 ; 0x24
> 1035f0: e1a0e00f mov lr, pc
> 1035f4: e1a0f003 mov pc, r3
> 1035f8: e3500000 cmp r0, #0 ; 0x0
> 1035fc: 191ba870 ldmnedb fp, {r4, r5, r6, fp, sp, pc}
> 103600: e51b2024 ldr r2, [fp, -#36]
> 103604: eafffff3 b 1035d8 <cyg_io_lookup+0x88>
And here we go recursive, calling cyg_io_lookup.
> 103608: e24b1020 sub r1, fp, #32 ; 0x20
> 10360c: ebffffcf bl 103550 <cyg_io_lookup>
> 103610: e3500000 cmp r0, #0 ; 0x0
> 103614: 191ba870 ldmnedb fp, {r4, r5, r6, fp, sp, pc}
> 103618: e51b2024 ldr r2, [fp, -#36]
> 10361c: eaffffea b 1035cc <cyg_io_lookup+0x7c>
> 103620: 002005c0 eoreq r0, r0, r0, asr #11
> 103624: 00200630 eoreq r0, r0, r0, lsr r6
> cut....
>
> The "problematic" statement is at address 103590.
The assembly looks correct, but maybe i'm missing a detail. You need
to single step at the instruction level. With the gdb CLI, that is
stepi. How you do that in a IDE i've no idea.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
