From owner-freebsd-arm@freebsd.org Mon Oct 26 09:26:56 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64506A1C44D for ; Mon, 26 Oct 2015 09:26:56 +0000 (UTC) (envelope-from mattia.rossi.mailinglists@gmail.com) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E63111904; Mon, 26 Oct 2015 09:26:55 +0000 (UTC) (envelope-from mattia.rossi.mailinglists@gmail.com) Received: by wicfv8 with SMTP id fv8so106278052wic.0; Mon, 26 Oct 2015 02:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=IV1d1jQwRlATPGgOEf266yg0904bz2btaHlMSOUj8iA=; b=NZilMw9zMpJzhPwI7iNoo1a0lt+/uYJvh1uGyosuwD/OUtNFf2a3XzexXMidiCV/fp RQ+GgYt6XnJUt1kOWKg7UViT5qZsdr5voK9a9BZYJLgOywSXhxQq7fG1LCLCcDkdmoy2 iUw+vSJHwd9Iy0oOZ47tjSRzmBbonvJh+aCC5gG+K20mme71IvGgF7e0RVTGLWR9ld+m BQIv3ILqRTbVEMu4y95vxlwdRyr1V197CRbrob88zHU9jkKQN+0L77Wml9hSSFSUnVX9 eDXcEX5u2pHS8ZjgLJJZKBQcqYjvShgomyACFYTwgpSIFQFDTDd/aPo9lg6MVL/8KKe7 KiKA== X-Received: by 10.194.109.99 with SMTP id hr3mr13025140wjb.25.1445851614457; Mon, 26 Oct 2015 02:26:54 -0700 (PDT) Received: from [192.168.0.113] (82.50.202.62.static.wline.lns.sme.cust.swisscom.ch. [62.202.50.82]) by smtp.googlemail.com with ESMTPSA id uj4sm37924490wjc.34.2015.10.26.02.26.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Oct 2015 02:26:53 -0700 (PDT) Subject: Re: CC core dumping with CLANG 3.7 on armv5 - DREAMPLUG To: Ian Lepore , Konstantin Belousov References: <5626144F.9060003@gmail.com> <5628873F.7050509@gmail.com> <20151022081551.GB2257@kib.kiev.ua> <5628B0B0.8040804@gmail.com> <20151022111407.GD2257@kib.kiev.ua> <5628D958.4060904@gmail.com> <5628D9F8.8040206@gmail.com> <1445625017.91534.31.camel@freebsd.org> Cc: freebsd-arm From: Mattia Rossi Message-ID: <562DF1DD.5040408@gmail.com> Date: Mon, 26 Oct 2015 10:26:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1445625017.91534.31.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 09:26:56 -0000 Am 23.10.2015 um 20:30 schrieb Ian Lepore: > On Thu, 2015-10-22 at 14:43 +0200, Mattia Rossi wrote: >> Am 22.10.2015 um 14:40 schrieb Mattia Rossi: >>> >>> Am 22.10.2015 um 13:14 schrieb Konstantin Belousov: >>>> On Thu, Oct 22, 2015 at 11:47:28AM +0200, Mattia Rossi wrote: >>>>>> You may disassemble the instruction at the address, and print >>>>>> the >>>>>> content >>>>>> of registers: >>>>>> (gdb) disassemble *0x01eb0868-8,0x01eb0868+8 >>>>>> (gdb) info registers >>>>>> >>>>>> If the cause of your issue is weird codegeneration on ARMv5, >>>>>> it >>>>>> might be >>>>>> seen from the data above. On the other hand, this would not >>>>>> help >>>>>> if the >>>>>> issue is algorithmic. I am afraid there is not much more to >>>>>> suggest. >>>>> (gdb) disassemble *0x01eb0868-8,0x01eb0868+8 >>>>> No function contains specified address. >>>> Apparently correct syntax is >>>> disassemble 0x01eb0868-8 0x01eb0868+8 >>> (gdb) bt >>> #0 0x01eb0868 in ?? () >>> (gdb) disassemble 0x01eb0868-8 0x01eb0868+8 >>> Dump of assembler code from 0x1eb0860 to 0x1eb0870: >>> 0x01eb0860: add r12, r12, #1 ; 0x1 >>> 0x01eb0864: and r7, r0, r3 >>> 0x01eb0868: ldr r1, [r10, r7, lsl #2] >>> 0x01eb086c: cmp r1, #0 ; 0x0 >>> End of assembler dump. >>> (gdb) info registers >>> r0 0x1e53b 124219 >>> r1 0x6a 106 >>> r2 0xc3c3c3c6 -1010580538 >>> r3 0x5a5a5a59 1515870809 >>> r4 0x3 3 >>> r5 0x1fd9f83 33398659 >>> r6 0x1e53b 124219 >>> r7 0x4019 16409 >>> r8 0x22a1708c 581005452 >>> r9 0xffffffff -1 >>> r10 0x5a5a5a5a 1515870810 >>> r11 0xbfbfeb70 -1077941392 >>> r12 0x1 1 >>> sp 0xbfbfeb48 -1077941432 >>> lr 0x8f5c 36700 >>> pc 0x1eb0868 32180328 >>> fps 0x0 0 >>> cpsr 0x60000010 1610612752 >>> (gdb) >>> >>> Still I can't tell anything from that :-/ - way too low level for >>> me >> Btw. I'm currently using a helloworld program for testing: >> >> root@dreamplug:~ # cat helloworld.c >> /* Hello World program */ >> >> #include >> >> main() >> { >> printf("Hello World"); >> >> >> } >> > I think the degenerate testcase for this is just typing 'cpp', and the > first line of output when you do might be a clue... > > root@dpnand:/root # cpp > error: no handler registered for module format 'raw' > fatal error: error in backend: unknown module format > cpp: error: clang frontend command failed with exit code 70 (use -v to see invocation) > FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906 > Target: arm--freebsd11.0-gnueabi > Thread model: posix > cpp: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. > cpp: note: diagnostic msg: Error generating preprocessed source(s) - ignoring input from stdin. > cpp: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs. > > With a quick glance at the code involved, that "no handler" message > happens when it can't find the requested module type in a container of > module handlers. But the default constructor for the container > automatically adds the handler for 'raw' so not finding it seems > insane. I don't know how to proceed from here in debugging. > Unfortunately, we have no functional arm emulator (only armv6 and the > problem doesn't happen there) so this has to be debugged on real > hardware I guess. I'd love to do some more debugging to get this fixed. Is there a quick way to just get debugging symbols in CLANG instead of having to compile world with it (and running out of swap space?) Cheers, Mat