From owner-freebsd-arm@FreeBSD.ORG Fri Jan 10 23:41:38 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44168D6C; Fri, 10 Jan 2014 23:41:38 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 13D491B63; Fri, 10 Jan 2014 23:41:37 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W1lhi-000CYF-VA; Fri, 10 Jan 2014 23:41:31 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s0ANfRTf033398; Fri, 10 Jan 2014 16:41:27 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/HiZM1Fa5UuvPB1ERDpQWV Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa From: Ian Lepore To: John-Mark Gurney 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> Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Jan 2014 16:41:27 -0700 Message-ID: <1389397287.1158.462.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: andrew@FreeBSD.org, freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 23:41:38 -0000 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 > > > 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