Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 17 Feb 2015 09:20:38 +0000
From: David Guillen <>
Subject: Re: Executable crashes at __libc_start_main


The toolchain is a "buildroot" one, so it _should_ be OK. The funny
think as I said is that it works well on some ARM boxes and qemu, so
it might be something related to the

Rich: R5 is OK, it points to the following 4 bytes (due to
postincrement), so I guess it must be OK before the load. And BTW I'm
not using thumb code, all instructions are ARM 32 bit wide


2015-02-17 6:49 GMT+00:00 Igmar Palsenberg <>:
>> 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.
> You're absolutely sure your toolchain is OK ? Hard to track issues like
> this are usually caused by a wrong toolchain, and ARM has some nice quirks
> when it comes to this.
>         Igmar

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.