From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7060 Path: news.gmane.org!not-for-mail From: David Guillen Fandos Newsgroups: gmane.linux.lib.musl.general Subject: Executable crashes at __libc_start_main Date: Tue, 17 Feb 2015 01:41:00 +0000 Message-ID: <54E29C2C.5080907@davidgf.es> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1424137289 21507 80.91.229.3 (17 Feb 2015 01:41:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Feb 2015 01:41:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7073-gllmg-musl=m.gmane.org@lists.openwall.com Tue Feb 17 02:41:29 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YNXAG-0005Wu-Bm for gllmg-musl@m.gmane.org; Tue, 17 Feb 2015 02:41:28 +0100 Original-Received: (qmail 18327 invoked by uid 550); 17 Feb 2015 01:41:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 18245 invoked from network); 17 Feb 2015 01:41:13 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=VSfElDk6XLT2lb2GxohrWzs/5sZqNCv/jDfePLExoZ0=; b=gBfU2AF0p8hPELabSPFLK/JpzJ5peYiTbsAtuj4Qo3jUgzO4ssil+XLsZNVJ5G5YtA N2jQyQ3PM38N3Gyg83aILfmOIn25oD6/qfpM5UQECUaXLxvHFnk5HVm/vRxZ0nT8vJ8H uc7iv8kZ3Nnlt/KCL3xAELRjJgMMixNqu+gWYFKFsPAnTOX+0DNZ8fn51SIOgRM6ZmDt VaqsHyes9/VwEjJCD32UTQU6Nhi0j4dinAzC6cHMwwY+GyQ3nRDEVa1hsu4utPEXLyjm 0PY17Z4J6nksc5+I/6L0pjUTzDDLanMyf67k0WkT00G6s+pDPQKvkYWzWWeJslWpN9zP hm/Q== X-Gm-Message-State: ALoCoQl0m9v8bM2bBVXv4lhkk1VhsFq7ip5F05FkW1DlhGEISHVQhc556otTMGtONUGEIWgMcm/3 X-Received: by 10.194.121.168 with SMTP id ll8mr42007857wjb.35.1424137262462; Mon, 16 Feb 2015 17:41:02 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 Xref: news.gmane.org gmane.linux.lib.musl.general:7060 Archived-At: Hello! I'm creating an app which is an ARM ELF (linux) which runs in very small machines (routers). Using buildroot to create my toolchain I can choose between uClibc and musl. Using uclibc my binary crashes at loading, so I switched to musl and tried. It fails too. The problem seems to be at __libc_start_main, in this part: uintptr_t a = (uintptr_t)&__init_array_start; for (; a<(uintptr_t)&__init_array_end; a+=sizeof(void(*)())) (*(void (**)())a)(); I checked a little bit (dumping the map file) and I get: .init_array 0x0000000000016230 0x4 0x0000000000016230 PROVIDE (__init_array_start, .) *(SORT(.init_array.*)) *(.init_array) .init_array 0x0000000000016230 0x4 /XXX/arm-buildroot-linux-musleabi/4.8.3/crtbeginT.o 0x0000000000016234 PROVIDE (__init_array_end, .) .fini_array 0x0000000000016234 0x4 0x0000000000016234 Which tells me there is only one function pointer there. Now dumping the binary: 00016230 <__frame_dummy_init_array_entry>: 16230: 00008210 andeq r8, r0, r0, lsl r2 Disassembly of section .fini_array: Which is pointer 0x8210 which points to function: 00008210 : 8210: e92d4008 push {r3, lr} 8214: e59f3034 ldr r3, [pc, #52] ; 8250 8218: e3530000 cmp r3, #0 ... So far so good. The binary runs OK on a ARM machine running Debian, but when I run this program on this other machine it crashes. The CPU is: ARMv6-compatible processor rev 7 (v6l) CPU implementer : 0x41 CPU architecture: 6TEJ CPU variant : 0x0 CPU part : 0xb76 CPU revision : 7 Finally I got a core dump and the program crashes here: 88c8: e1550007 cmp r5, r7 88cc: 2a000003 bcs 88e0 <__libc_start_main+0x1b0> 88d0: e4953004 ldr r3, [r5], #4 88d4: e1a0e00f mov lr, pc 88d8: e12fff13 bx r3 88dc: eafffff9 b 88c8 <__libc_start_main+0x198> In the 88d8 instruction to be more exact. Seems that R3 is holding the value 0xc8000082!!! Where is that 0xC8 at the beginning comming from? The PC reported by the core dump is 0xc8000080 which I guess it's just the vlaue of R3 aligned to 4 byte boundary. R5 points to the right place, it's just the value loaded by the load. Could it be that something corrupts my ELF? Could it be the OS being really dumb at loading the ELF? It's a pretty old kernel, 2.6.21. Thanks a lot! David