[uClibc]Re: 2.5.30-rmk1-pxa1 uClibc failures

[Christopher Hoover]

I have had good success with uClibc <= 0.9.12 on 2.5.x on ARM.  In
particular, 2.5.30-rmk1/gcc 3.1/uClibc 0.9.12 works fabulously.

Today I built gcc 3.2/uClibc 0.9.15 and re-compiled my user space.  I'm
running the same kernel (i.e. exact same bits in the flash) that ran
well with my previous 0.9.12-based user space.  I am seeing some
potential regression.  

The first thing that I noticed is that utelnetd crashes when a client
attempts a connection.   It worked fine under 0.9.12. 

I haven't had a chance to track this down.  Details follow.

-ch
ch at murgatroid.com
ch at hpl.hp.com

{client connects, boom!}
utelnetd: unhandled page fault at 0x00000000, code 0xc3eaf007
pgd = c3eac000
[00000000] *pgd=c3da8001, *pte=00000000, *ppte=00000000
pc : [<4002fabc>]    lr : [<0000919c>]    Not tainted
sp : bffffc48  ip : 4002fab8  fp : bffffca8
r10: 4004fe7c  r9 : 00000000  r8 : 00000000
r7 : 00000004  r6 : bffffea4  r5 : bffffeb8  r4 : 00017000
r3 : 00000000  r2 : 000128cc  r1 : 00000000  r0 : 000128cc
Flags: nzCv  IRQs on  FIQs on  Mode USER_32  Segment user
Control: C3EAF17F  Table: C3EAF17F  DAC: 00000015


00009104 <getpty>:
    9104:	e1a0c00d 	mov	ip, sp
    9108:	e92dd800 	stmdb	sp!, {fp, ip, lr, pc}
    910c:	e24cb004 	sub	fp, ip, #4	; 0x4
    9110:	e24dd054 	sub	sp, sp, #84	; 0x54
    9114:	e50b0010 	str	r0, [fp, -#16]
    9118:	ebfffe5d 	bl	8a94 <_init+0xc0>
    911c:	e1a03000 	mov	r3, r0
    9120:	e50b3054 	str	r3, [fp, -#84]
    9124:	e51b3054 	ldr	r3, [fp, -#84]
    9128:	e3530000 	cmp	r3, #0	; 0x0
    912c:	aa000004 	bge	9144 <getpty+0x40>

    9130:	e51b0054 	ldr	r0, [fp, -#84]
    9134:	ebfffede 	bl	8cb4 <_init+0x2e0>
    9138:	e3e03000 	mvn	r3, #0	; 0x0
    913c:	e50b3060 	str	r3, [fp, -#96]
    9140:	ea000017 	b	91a4 <getpty+0xa0>

    9144:	e51b0054 	ldr	r0, [fp, -#84]
    9148:	ebfffe99 	bl	8bb4 <_init+0x1e0>
    914c:	e1a03000 	mov	r3, r0
    9150:	e3530000 	cmp	r3, #0	; 0x0
    9154:	ba000005 	blt	9170 <getpty+0x6c>

    9158:	e51b0054 	ldr	r0, [fp, -#84]
    915c:	ebfffe68 	bl	8b04 <_init+0x130>
    9160:	e1a03000 	mov	r3, r0
    9164:	e3530000 	cmp	r3, #0	; 0x0
    9168:	ba000000 	blt	9170 <getpty+0x6c>
    916c:	ea000004 	b	9184 <getpty+0x80>

    9170:	e51b0054 	ldr	r0, [fp, -#84]
    9174:	ebfffece 	bl	8cb4 <_init+0x2e0>
    9178:	e3e03000 	mvn	r3, #0	; 0x0
    917c:	e50b3060 	str	r3, [fp, -#96]
    9180:	ea000007 	b	91a4 <getpty+0xa0>

    9184:	e51b0054 	ldr	r0, [fp, -#84]
    9188:	ebfffe99 	bl	8bf4 <_init+0x220>
    918c:	e1a03000 	mov	r3, r0
    9190:	e51b0010 	ldr	r0, [fp, -#16]
    9194:	e1a01003 	mov	r1, r3
    9198:	ebfffe15 	bl	89f4 <_init+0x20>

lr->
    919c:	e51b3054 	ldr	r3, [fp, -#84]
    91a0:	e50b3060 	str	r3, [fp, -#96]

    91a4:	e51b0060 	ldr	r0, [fp, -#96]
    91a8:	e91ba800 	ldmdb	fp, {fp, sp, pc}


init+0x20:
    89f4:	e59fc004 	ldr	ip, [pc, #4]	; 8a00
<_init+0x2c>
    89f8:	e08fc00c 	add	ip, pc, ip
    89fc:	e59cf000 	ldr	pc, [ip]
    8a00:	00009dec 	andeq	r9, r0, ip, ror #27


Here's the C code for utelnetd.c:getpty():

static int getpty(char *line)
{
        struct stat stb;
        int p;
        int i;
        int j;

        p = getpt();
        if (p < 0) {
                DEBUG_OUT("getpty(): couldn't get pty\n");
                close(p);
                return -1;
        }
        if (grantpt(p)<0 || unlockpt(p)<0) {
                DEBUG_OUT("getpty(): couldn't grant and unlock pty\n");
                close(p);
                return -1;
        }
        DEBUG_OUT("getpty(): got pty %s\n",ptsname(p));
        strcpy(line, (const char*)ptsname(p));

        return(p);
}