From owner-freebsd-arm@FreeBSD.ORG Sat Jan 11 04:37:41 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 150E0DEE for ; Sat, 11 Jan 2014 04:37:41 +0000 (UTC) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CD5F51FD2 for ; Sat, 11 Jan 2014 04:37:40 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id ar20so1874774iec.39 for ; Fri, 10 Jan 2014 20:37:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=sQycZA7aQnIzEAZ47aH+PkKhZlG7+5ERivPxPBQJ0UU=; b=Y3dDItCPyHXmua5HSs5AKzV6menYZmQVFGIhuyIkKouW46dT5p4/SOOT1mdhB2bfO9 NA6Obl9jcIthJIxvl/qZRh1PJOA3AeAL4jXTUELHw3iYSthrCAImvBiXxyjSR46bM17/ vQWZKqHShwWzcwaAuCawU33KJwMstJfB6EQpgtf9jUMRlKXdkvypHqEuNp/PqEPtPHHC otaD2zV/rIBAF5sObhcUAAfdJLuJX2Bt6fS8XXbWEXOMDEYdxwgvJ/W+gLaq423ChyEZ bNJG2zC4k9TPWYnqKq+5uX77FW4mR3tWl9J6eV8MU1xQrvsHwdWx+9SDHWKMQAJI9Jfa VdrA== X-Gm-Message-State: ALoCoQlyRsLPoKjw48gBDNUhqhRf9A39/2DjpD/kLD8Y6lRSAgsT0A5RRhOvszwsaOqze6nZOWxb X-Received: by 10.43.138.8 with SMTP id iq8mr11560152icc.37.1389415053811; Fri, 10 Jan 2014 20:37:33 -0800 (PST) Received: from fusion-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id u1sm6350762ige.1.2014.01.10.20.37.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Jan 2014 20:37:33 -0800 (PST) Sender: Warner Losh Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20140111002648.GT46596@funkthat.com> Date: Fri, 10 Jan 2014 21:37:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <1389397287.1158.462.camel@revolution.hippie.lan> <20140111002648.GT46596@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1085) Cc: andrew@FreeBSD.org, freebsd-arm@FreeBSD.org, Ian Lepore 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: Sat, 11 Jan 2014 04:37:41 -0000 On Jan 10, 2014, at 5:26 PM, John-Mark Gurney wrote: > Ian Lepore wrote this message on Fri, Jan 10, 2014 at 16:41 -0700: >> 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... >>>>=20 >>>> 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... >>>>=20 >>>> So, it is clearly changing something very early on in boot... >>>=20 >>> Apparently gcc ARMEB w/ EABI miscompiles code... The code to store >>> lo_flags in the lock_object is correct: >>> lock->lo_flags =3D i << LO_CLASSSHIFT; >>> c03ce2d0: e1a01c06 lsl r1, r6, #24 >>> c03ce2d4: e5881004 str r1, [r8, #4] >>>=20 >>> 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 >>>=20 >>>=20 >>> 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... >>>=20 >>> Anyone who know gcc arm well to figure this out? >>>=20 >>=20 >> 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? >=20 > In a generated test case, even -O1 produces broken code... Only -O0 > looks like it produces correct code, though the code is so much more > verbose, it takes more work to verify... Maybe there's a specific optimization that can be disabled instead? = Maybe you can try the ones that are enabled between O0 and O1. Since you = have the setup, maybe you could look... Warner > code: > int > foo(int *b) > { > return (*b & 0xf000000) >> 24; > } >=20 > -O0: > 00000000 : > 0: e1a0c00d mov ip, sp > 4: e92dd800 push {fp, ip, lr, pc} > 8: e24cb004 sub fp, ip, #4 ; 0x4 > c: e24dd004 sub sp, sp, #4 ; 0x4 > 10: e50b0010 str r0, [fp, #-16] > 14: e51b3010 ldr r3, [fp, #-16] > 18: e5933000 ldr r3, [r3] > 1c: e203340f and r3, r3, #251658240 ; 0xf000000 > 20: e1a03c43 asr r3, r3, #24 > 24: e1a00003 mov r0, r3 > 28: e89da808 ldm sp, {r3, fp, sp, pc} >=20 > -O1 & -O2: > 00000000 : > 0: e5d00000 ldrb r0, [r0] > 4: e200000f and r0, r0, #15 ; 0xf > 8: e12fff1e bx lr >=20 > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"