[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 17 Feb 2015 17:31:38 +0000
From: David Guillen Fandos <david@...idgf.es>
CC: musl@...ts.openwall.com
Subject: Re: Executable crashes at __libc_start_main
I checked the core dump.
At addr 0x00016230 (init_array) value is 0xc8000082 as reported by r3.
So either someone corrupted it or the OS corrupted it at loading.
The mentioned platform does not ship gdb. Any idea on how to "debug"
this? Even if it shipped gdb I don't think the error would be
reproducible, since it works great on other ARM systems.
Thanks!
David
El 17/02/15 a las 15:46, Rich Felker escribió:
> On Tue, Feb 17, 2015 at 09:20:38AM +0000, David Guillen wrote:
>> 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.
>
> That code is not supposed to be compiled at all in shared libc, only
> static, and for static there is no "ld-linux". Also the dynamic linker
> should be ld-musl-arm.so.1; if it's using ld-linux that's a foreign
> dynamic linker that's not going to work.
>
>> 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.
>
> Sorry, I misread the address column as the instruction encoding when I
> saw just 4 hex digits. :-) So that's not the issue.
>
> Can you dump the address range for __init_array_start at runtime in
> gdb using the x command?
>
> Rich
>
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.
