From owner-freebsd-arm@freebsd.org Mon Oct 26 12:26:28 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 E0A86A1AFFA for ; Mon, 26 Oct 2015 12:26:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 883C91350; Mon, 26 Oct 2015 12:26:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id t9QCQHLO000947 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 26 Oct 2015 14:26:18 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua t9QCQHLO000947 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id t9QCQHiM000946; Mon, 26 Oct 2015 14:26:17 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 26 Oct 2015 14:26:17 +0200 From: Konstantin Belousov To: Mattia Rossi Cc: Ian Lepore , freebsd-arm Subject: Re: CC core dumping with CLANG 3.7 on armv5 - DREAMPLUG Message-ID: <20151026122617.GR2257@kib.kiev.ua> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <562DF1DD.5040408@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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:26:29 -0000 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.