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