This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Simulating arm-linux binaries


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]