Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Oct 2015 16:33:18 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Mattia Rossi <mattia.rossi.mailinglists@gmail.com>
Cc:        freebsd-arm <freebsd-arm@freebsd.org>
Subject:   Re: CC core dumping with CLANG 3.7 on armv5 - DREAMPLUG
Message-ID:  <20151022133318.GE2257@kib.kiev.ua>
In-Reply-To: <5628D958.4060904@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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151022133318.GE2257>