CC core dumping with CLANG 3.7 on armv5 - DREAMPLUG

[Mattia Rossi]

Am 22.10.2015 um 15:33 schrieb Konstantin Belousov:
> On Thu, Oct 22, 2015 at 02:40:56PM +0200, Mattia Rossi wrote:
>>
>> 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
> r10, which is the base register in the faulted instruction, contains the
> 0x5a5a5a5a value.  This pattern is filled by the debugging version of
> malloc to catch dereferences through the pointers located in freed
> memory.  On the other hand, the asm itself looks relatively reasonable.
>
> The issue looks as the clang bug.  But, without proper backtrace and
> line numbers, I doubt that clang developers would be able to make any
> further investigation.
Thanks for the explanation. Is there any way to build just clang with 
debugging symbols? I've tried cd-ing into usr.bin/clang/ and issue "make 
obj all install" with the proper targets set, but that complains about 
src.bsd.mk not being found and bails out...