From owner-freebsd-arm@FreeBSD.ORG Sat Jan 11 00:26:50 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32D8B5AE; Sat, 11 Jan 2014 00:26:50 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 08ADB1EE2; Sat, 11 Jan 2014 00:26:49 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s0B0Qmij079024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jan 2014 16:26:49 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s0B0Qmno079023; Fri, 10 Jan 2014 16:26:48 -0800 (PST) (envelope-from jmg) Date: Fri, 10 Jan 2014 16:26:48 -0800 From: John-Mark Gurney To: Ian Lepore Subject: Re: svn commit: r258412 - in head/sys/arm: at91 econa s3c2xx0 sa11x0 xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa Message-ID: <20140111002648.GT46596@funkthat.com> Mail-Followup-To: Ian Lepore , freebsd-arm@FreeBSD.org, andrew@FreeBSD.org 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1389397287.1158.462.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 10 Jan 2014 16:26:49 -0800 (PST) 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: Sat, 11 Jan 2014 00:26:50 -0000 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... > > > > > > 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? 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... code: int foo(int *b) { return (*b & 0xf000000) >> 24; } -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} -O1 & -O2: 00000000 : 0: e5d00000 ldrb r0, [r0] 4: e200000f and r0, r0, #15 ; 0xf 8: e12fff1e bx lr -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."