CC core dumping with CLANG 3.7 on armv5 - DREAMPLUG

[Mattia Rossi]

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 at 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 at 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