Date: Mon, 26 Oct 2015 13:59:08 +0100 From: Mattia Rossi <mattia.rossi.mailinglists@gmail.com> To: Konstantin Belousov <kostikbel@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: <562E239C.9030209@gmail.com> In-Reply-To: <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> <20151026122617.GR2257@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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<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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?562E239C.9030209>