Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Jan 2014 16:41:27 -0700
From:      Ian Lepore <ian@FreeBSD.org>
To:        John-Mark Gurney <jmg@funkthat.com>
Cc:        andrew@FreeBSD.org, freebsd-arm@FreeBSD.org
Subject:   Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa
Message-ID:  <1389397287.1158.462.camel@revolution.hippie.lan>
In-Reply-To: <20140110230241.GS46596@funkthat.com>
References:  <201311210108.rAL18AoQ051365@svn.freebsd.org> <20131221061048.GC99167@funkthat.com> <20140108071643.GB99167@funkthat.com> <1389197091.1158.370.camel@revolution.hippie.lan> <20140108173909.GF99167@funkthat.com> <20140110230241.GS46596@funkthat.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2014-01-10 at 15:02 -0800, John-Mark Gurney wrote:
> John-Mark Gurney wrote this message on Wed, Jan 08, 2014 at 09:39 -0800:
> > So, I've tested that HEAD (absolutely no tree changes) w/
> > WITHOUT_ARM_EABI boots fine...  and just to make sure my test is
> > correct, I've disabled it too to verify that the kernel just hangs
> > (absolutely no output)..  and reenabled it and verified it works (that
> > my setting is changing something)...
> > worky -> no worky -> worky...
> > 
> > Now I just realized another interesting thing about setting
> > WITHOUT_ARM_EABI, it also fixes the console issue I was having w/ your
> > call to cpu_setup("") previously (w/ EABI) killing console output and
> > not even seeing the mtx panic message...
> > 
> > So, it is clearly changing something very early on in boot...
> 
> Apparently gcc ARMEB w/ EABI miscompiles code...  The code to store
> lo_flags in the lock_object is correct:
>                         lock->lo_flags = i << LO_CLASSSHIFT;
> c03ce2d0:       e1a01c06        lsl     r1, r6, #24
> c03ce2d4:       e5881004        str     r1, [r8, #4]
> 
> But when I add a printf to fetch the data, I get:
> printf("lo_classindex: %#x\n", LO_CLASSINDEX(lock));
> c03ce2e0:       e5d81007        ldrb    r1, [r8, #7]
> c03ce2e4:       e59f0098        ldr     r0, [pc, #152]  ; c03ce384 <_end+0xffcf9
> 19c>
> c03ce2e8:       e201100f        and     r1, r1, #15     ; 0xf
> c03ce2ec:       eb0012ea        bl      c03d2e9c <printf>
> 
> 
> We are doing a ldrb (LoaD Relative Byte) which would be fine to
> substitute for the right shift of 24, but only if it loaded the correct
> byte.. It should be loading #4 instead of #7 since we are on big
> endian...
> 
> Anyone who know gcc arm well to figure this out?
> 

The generated byte-load code is enough different from the literal "load
32 bits and shift" of LO_CLASSINDEX() that the optimizer must have
messed it up.  Do we build the kernel with -O2, and if so would -O1
help?

-- Ian






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