Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Jun 2014 20:08:27 +0100
From:      Andrew Turner <andrew@fubar.geek.nz>
To:        John-Mark Gurney <jmg@funkthat.com>
Cc:        arm@FreeBSD.org
Subject:   Re: AVILA getting close!
Message-ID:  <20140620200827.1c33c7da@bender.Home>
In-Reply-To: <20140620151023.GZ31367@funkthat.com>
References:  <20140618225808.GG31367@funkthat.com> <20140620151023.GZ31367@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Jun 2014 08:10:24 -0700
John-Mark Gurney <jmg@funkthat.com> wrote:

> John-Mark Gurney wrote this message on Wed, Jun 18, 2014 at 15:58
> -0700:
> > So, w/ the recent couple of patches that alc has provided, I no
> > longer receive kernel panics on my AVILA board!
> > 
> > $ uname -a
> > FreeBSD avila.funkthat.com 11.0-CURRENT FreeBSD 11.0-CURRENT #27
> > r267333:267349M: Wed Jun 11 09:57:58 PDT 2014
> > jmg@carbon.funkthat.com:/usr/obj/arm.armeb/usr/src.avila/sys/AVILA
> > arm $ uptime 12:15AM  up 1 day, 15 mins, 2 users, load averages:
> > 0.13, 0.11, 0.08
> > 
> > This survived a portsnap extract...  This is all over NFS...
> > 
> > Though the issue that I'm now having is that some binaries
> > (newsyslog) and sometimes other binaries (awk, grep) core dump...
> > 
> > I believe this is an issue w/ rtld, or related...  If I compile
> > newsyslog -static, it works fine...  Otherwise I get a SIGILL, and
> > that is because it jumps off into the weeds..  Though gdb on arm
> > isn't very useful..
> 
> ok, so the SIGILL only occures under gdb, and this is because single
> stepping into a RAS sequence doesn't work very well...  If you set a
> break point on the return (after the RAS sequence), you can get past
> this...
> 
> I got to the point in rtld.c code:
>     if (obj->pltrel)
>         rel = (const Elf_Rel *) ((caddr_t) obj->pltrel + reloff);
>     else
>         rel = (const Elf_Rel *) ((caddr_t) obj->pltrela + reloffand
> was seeing gdb try to execute the pltrela line, but: i;
> 
> and was seeing gdb try to execute the pltrela line, but:
> (gdb) print * (const Elf_Rel *) ((caddr_t) obj->pltrela + reloff)
> Error accessing memory address 0x118: Bad address.
> (gdb) print/x obj->pltrela
> $4 = 0x0
> (gdb) print /x reloff
> $5 = 0x118
> (gdb) print obj->pltrel
> $6 = (const Elf_Rel *) 0x94e8
Based on my copy of newsyslog I built for armeb this looks correct. To
verify it could you dump the .dynamic section from the binary?
Something like 'objdump -s newsyslog' will get it.

> Hun? obj->pltrel is non-zero, so it should have executed the other
> line...
> 
> I recompiled rtld w/ -O0, and sure enough, newsyslog runs fine... If
> I compile w/o -O, or w/ -O1, it fails...
> 
> Comments or suggestions?
> 

What is the value of rel after the if statement? In the -O/-O1 case the
asm looks like:

ldr     r2, [sp, #20]  ; Load obj to r2
ldr     r3, [r2, #124] ; Load obj->pltrel to r3
cmp     r3, #0  ; 0x0  ; if obj->pltrel:
ldrne   r2, [sp, #16]  ;  != NULL: Load reloff to r2
addne   r4, r3, r2     ;  != NULL: Add obj->pltrel + reloff to r4
ldreq   r2, [sp, #20]  ;  == NULL: Load obj to r2
ldreq   r3, [r2, #132] ;  == NULL: Load obj->pltrela to r3
ldreq   r2, [sp, #16]  ;  == NULL: Load reloff to r2
addeq   r4, r2, r3     ;  == NULL: Add obj->pltrela + reloff to r4

Given this I could see how gdb gets confused.

It may also pay to get the registers from gdb at this point.

Andrew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140620200827.1c33c7da>