This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Simulating arm-linux binaries
- From: Shaun Jackman <sjackman at gmail dot com>
- To: gdb at sources dot redhat dot com
- Date: Mon, 14 Nov 2005 15:28:47 -0700
- Subject: Simulating arm-linux binaries
- Reply-to: Shaun Jackman <sjackman at gmail dot com>
Hello,
I'm adding support to sim/arm (arm-elf-run) to run statically linked
Linux binaries. The work is going well so far; I'm already able to run
a "Hello, world!" application linked against uClibc. Running a "Hello,
world!" application linked against glibc is proving to be a little
more difficult. If anyone else is interested in this work, and perhaps
in helping with this work, I'll send my current patch your way. I'll
be sending a patch upstream that works with uClibc shortly.
It irks me, though, that glibc isn't yet working. Particularly
annoying is that arm-elf-run and arm-elf-gdb 'target sim' are giving
different results. When I call arm-elf-run hello, glibc calls the
syscalls { uname, brk, brk mmap) and then dies shortly after the
simulated mmap fails (errno = ENOMEM) with unhandled instructions at
address 0x504 and 0x50c. When I run the same binary with arm-elf-gdb,
glibc calls the syscalls { uname, geteuid32, getuid32, getegid32,
getgid32, writev } and the writev call displays...
*** glibc detected *** corrupted double-linked list: 0xff00006d ***
These two invocations of the same binary seem to be going down very
different code paths within glibc. Any idea why that is? Is gdb
calling the ARMulator differently somehow than sim?
Cheers,
Shaun