From owner-freebsd-arm@freebsd.org Mon Oct 26 12:59:11 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 2E75F8FB5 for ; Mon, 26 Oct 2015 12:59:11 +0000 (UTC) (envelope-from mattia.rossi.mailinglists@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 C5AB31DC0; Mon, 26 Oct 2015 12:59:10 +0000 (UTC) (envelope-from mattia.rossi.mailinglists@gmail.com) Received: by wicfv8 with SMTP id fv8so114740412wic.0; Mon, 26 Oct 2015 05:59:09 -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=TVvCA5f9smok5OP04l0+r7X5VtEzQ9IsDQad/x65neI=; b=z3VLwD3i+FiDM/mGlbgjMHBvQK8SizPIWCj/uCm7KNtNn0lGmyS/tgsWvWAGxnbVj5 js4JQ8JOXBvXi/WCo1wQrG7kifnaD+U7HFmgHVkBoOIC7HvQQZPKppGuR/2S/TyjNIhz T4ZTYBmsVjDtFdzXjI0wHvQAma4LgcWoMZ3B7s00op7ZZgFxkzjsaY4ADY5vsTYEk77B vuuU/46wmvOnBmZWpy17kUKCMMg7J53WOxzVfDJsWsbWj2E7b0YRufikefl73DfGiFcA Z2iUgy0rWqQLe4jqD4lSH3iUMazzc+sLsMcS/rog5BHggAo4lbXpx+v4KjnG8KySr+gC km8g== X-Received: by 10.180.198.12 with SMTP id iy12mr21483604wic.72.1445864349265; Mon, 26 Oct 2015 05:59:09 -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 gl4sm39018301wjd.49.2015.10.26.05.59.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Oct 2015 05:59:08 -0700 (PDT) Subject: Re: CC core dumping with CLANG 3.7 on armv5 - DREAMPLUG To: 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> <562DF1DD.5040408@gmail.com> <20151026122617.GR2257@kib.kiev.ua> Cc: Ian Lepore , freebsd-arm From: Mattia Rossi Message-ID: <562E239C.9030209@gmail.com> Date: Mon, 26 Oct 2015 13:59:08 +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: <20151026122617.GR2257@kib.kiev.ua> 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 12:59:11 -0000 Am 26.10.2015 um 13:26 schrieb Konstantin Belousov: > On Mon, Oct 26, 2015 at 10:26:53AM +0100, Mattia Rossi wrote: >> >> 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?) > Probably something like > cd /usr/src > (cd lib/clang && make clean all DEBUG_FLAGS=-g) > (cd usr.bin/clang && make clean all DEBUG_FLAGS=-g && make install DEBUG_FLAGS=-g) > > Might be, also build libc and libm with the debugging info, since clang > is linked statically, and if the problem is in base and not due to a > clang code, you would have to rebuild otherwise. > > But you should not see much difference comparing with the full world > rebuild, since buildworld time is mostly the clang build time. I am not > sure that the native build is a reasonable adventure, unless you want to > stress-test the native v5 pmap. Thanks, I'll make some changes to my build system to get world built with DEBUG_FLAGS=-g as it seems that otherwise I might get stuck again when debugging. Maybe in a weeks time I have some more info :-) Cheers, Mat