Re: [ECOS] cyg_io_lookup for /dev/tty0 fails

[Andrew Lunn <andrew at lunn dot ch>]

> ...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