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>