Date: Mon, 26 Oct 2015 14:26:17 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Mattia Rossi <mattia.rossi.mailinglists@gmail.com> Cc: Ian Lepore <ian@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: CC core dumping with CLANG 3.7 on armv5 - DREAMPLUG Message-ID: <20151026122617.GR2257@kib.kiev.ua> In-Reply-To: <562DF1DD.5040408@gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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<stdio.h>
> >>
> >> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151026122617.GR2257>