[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADQAGRMRKgebSTY40ixp2JmchSArvsPDEHpwn2cpTZYmQsbbzw@mail.gmail.com>
Date: Tue, 17 Feb 2015 09:20:38 +0000
From: David Guillen <david@...idgf.net>
To: musl@...ts.openwall.com
Subject: Re: Executable crashes at __libc_start_main
Hi,
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 ld-linux.so.
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
instructions.
Thanks
David
2015-02-17 6:49 GMT+00:00 Igmar Palsenberg <igmar@...senberg.com>:
>
>> 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.
