Date: Fri, 10 Jan 2014 15:02:41 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Ian Lepore <ian@FreeBSD.org>, freebsd-arm@FreeBSD.org Cc: andrew@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: <20140110230241.GS46596@funkthat.com> In-Reply-To: <20140108173909.GF99167@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140110230241.GS46596>