From owner-freebsd-arm@FreeBSD.ORG Mon May 6 05:40:00 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 381B1DEA for ; Mon, 6 May 2013 05:40:00 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 0A47AFCE for ; Mon, 6 May 2013 05:39:59 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r465dw9b032288; Mon, 6 May 2013 05:39:58 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id epqsv7tixpa5i5cih4v9hti5sn; Mon, 06 May 2013 05:39:57 +0000 (UTC) (envelope-from kientzle@freebsd.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1283) Subject: Re: Is this related to the general panic discussed in freebsd-current? From: Tim Kientzle In-Reply-To: Date: Sun, 5 May 2013 22:39:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <724191A9-57F4-4D66-9E4A-EBBC13BDC0D1@freebsd.org> References: <51835891.4050409@thieprojects.ch> <03971BD1-4ADE-4435-BDD0-B94B62634F1D@bsdimp.com> <5183BF8C.4040406@thieprojects.ch> <6D0E82C9-79D1-4804-9B39-3440F99AA8FE@kientzle.com> <20130505140006.0d671ba5@bender> <20130505233729.63ac23bc@bender.lan> To: freebsd-arm@freebsd.org, Andrew Turner X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 05:40:00 -0000 On May 5, 2013, at 4:20 PM, Tim Kientzle wrote: >=20 > On May 5, 2013, at 3:37 PM, Andrew Turner wrote: >=20 >> On Sun, 5 May 2013 09:37:48 -0700 >> Tim Kientzle wrote: >>> On May 5, 2013, at 6:00 AM, Andrew Turner wrote: >>>=20 >>>> On Sat, 4 May 2013 15:44:37 -0700 >>>> Tim Kientzle wrote: >>>>> I'm baffled. If I insert a printf into the loop in stack_capture, >>>>> the kernel boots. But the generated assembly looks perfectly >>>>> correct to me in either case. So inserting the printf must have >>>>> some side-effect. >>>>>=20 >>>>> The stack does end up aligned differently: The failing version >>>>> puts 16 bytes on the stack, the working version puts 24 bytes. >>>>> But I can't figure out how that would explain what I'm seeing... >>>>=20 >>>> It feels like an alignment issue but those stack sizes should both >>>> be valid. Are you able to send me the asm for the working and = broken >>>> versions of the function? >>>>=20 >>>> Also which ABI are you using? I have not been able to reproduce it >>>> with EABI, but that may have been because I have a patched clang >>>> I've been using to track down another issue. >>>=20 >>> I'm using whatever the default is in FreeBSD-CURRENT. I've seen >>> this consistently with both RaspberryPi and BeagleBone kernels >>> for the last few weeks. >> Ok, it's the old ABI. I note this function may be broken with EABI as >> it make assumptions on the layout of each frame. >=20 > Thought so. >=20 >>> /* Broken version */ >>> c0519cec : >>> void >>> stack_save(struct stack *st) >>> { >>> c0519cec: e92d4830 push {r4, r5, fp, lr} >>=20 >> This stack layout is incorrect. It should store (from a low address = to >> high address) r4, r5, fp, ip, lr and pc. >=20 > If I understand right, you're claiming that Clang is generating > a wrong preamble for OABI functions which is manifesting > as crashes in the stack-walking code. >=20 > I'm not sure I understand the frame layout you're saying it > should use, though. Pushing PC seems a very strange thing > to do on ARM. (Though it would seem to match = sys/arm/include/stack.h.) >=20 > It doesn't look like Clang/OABI is using the layout you suggest > anywhere in the kernel code: I grepped through the kernel > disassembly and found only a single instance of "fp, ip, lr, pc" > and that was from assembly. >=20 > It also looks like sys/arm/include/stack.h needs to be taught > about the difference between EABI and OABI. >=20 >> The unwind code following is >> incorrect for this stack layout. >=20 > Ah. I'll take another look. I hadn't tried to match up the offsets > to see if they made sense for the stack layout. >=20 > I could probably change this stack-walking code to > match the frame layout being used by Clang here, > but I'm not sure whether that's the "right" fix. Here's a version of stack_capture that allows a Clang-built OABI kernel with WITNESS enabled to boot: /* In sys/arm/arm/stack_machdep.c */ static void stack_capture(struct stack *st, u_int32_t *frame) { vm_offset_t callpc; stack_zero(st); while (INKERNEL(frame)) { callpc =3D frame[1]; if (stack_put(st, callpc) =3D=3D -1) break; frame =3D (u_int32_t *)(frame[0]); } } =46rom the above, it sounds like this should not be committed; rather, we should fix Clang's OABI support to emit the right frame layout. I've not yet started to look through Clang to try to figure out how to do that=85. Any pointers? ;-) Tim