Debugging An Arm Binary On An X86 Machine

[troika]

I have an application which runs smoothly on my development machine but occasionally segfaults when I run the cross-compiled binary on my Zaurus.  Debugging it on the Zaurus itself would be tedious.  So I'm using gdb's ARM simulator, but I only get so far:

$ file test.x
test.x: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped

$ arm-linux-nm test.x
0001043c ? _DYNAMIC
00010424 ? _GLOBAL_OFFSET_TABLE_
00008404 R _IO_stdin_used
00010418 ? __CTOR_END__
00010414 ? __CTOR_LIST__
00010420 ? __DTOR_END__
0001041c ? __DTOR_LIST__
000104dc A __bss_end__
000104dc A __bss_start
000104dc A __bss_start__
00010408 D __data_start
         w __deregister_frame_info
000083a8 t __do_global_ctors_aux
000082ec t __do_global_dtors_aux
000104dc A __end__
         w __gmon_start__
         U __libc_start_main@@GLIBC_2.0
         w __register_frame_info
000104dc A _bss_end__
000104dc A _edata
000104dc A _end
000083f0 ? _fini
00008238 ? _init
00008280 T _start
         U abort@@GLIBC_2.0
000082b4 t call_gmon_start
00010410 d completed.4
00010408 W data_start
0000835c t fini_dummy
00010414 d force_to_data
00010414 d force_to_data
000082b4 t gcc2_compiled.
000083a8 t gcc2_compiled.
000083f0 t gcc2_compiled.
000082ec t gcc2_compiled.
0000836c t gcc2_compiled.
000083e0 t init_dummy
0000836c T main
0001040c d p.3

$ arm-elf-gdb test.x
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf"...
(gdb) target sim
Connected to the simulator.
(gdb) load
Loading section .interp, size 0x13 vma 0x80f4
Loading section .note.ABI-tag, size 0x20 vma 0x8110
Loading section .hash, size 0x30 vma 0x8130
Loading section .dynsym, size 0x70 vma 0x8160
Loading section .dynstr, size 0x57 vma 0x81d0
Loading section .gnu.version, size 0xe vma 0x8228
Loading section .gnu.version_r, size 0x20 vma 0x8238
Loading section .rel.got, size 0x8 vma 0x8258
Loading section .rel.plt, size 0x20 vma 0x8260
Loading section .init, size 0x18 vma 0x8280
Loading section .plt, size 0x50 vma 0x8298
Loading section .text, size 0x158 vma 0x82e8
Loading section .fini, size 0x14 vma 0x8440
Loading section .rodata, size 0x10 vma 0x8454
Loading section .data, size 0xc vma 0x10464
Loading section .ctors, size 0x8 vma 0x10470
Loading section .dtors, size 0x8 vma 0x10478
Loading section .got, size 0x20 vma 0x10480
Loading section .dynamic, size 0xa0 vma 0x104a0
Start address 0x82e8
Transfer rate: 8704 bits in <1 sec.
(gdb) run
Starting program: [...]/test.x

Program exited with code 0324.
[Switching to process 0]
(gdb)


I imagine the simulation fails because it can't find some or all of these symbols:
         w __deregister_frame_info
         w __gmon_start__
         U __libc_start_main@@GLIBC_2.0
         w __register_frame_info
         U abort@@GLIBC_2.0


So how do I link libraries into the simulation?  I haven't found an answer in the gdb manual.

[lardman]

Not answering your question, but afaik, you can debug on the Zaurus using gdb and view the code remotely, or just do it all over ssh perhaps.

Si

[troika]

Not answering your question, but afaik, you can debug on the Zaurus using gdb and view the code remotely, or just do it all over ssh perhaps.

Si
[div align=\"right\"][a href=\"index.php?act=findpost&pid=125720\"][{POST_SNAPBACK}][/a][/div]

Yeah, I've been trying to debug the program on my 5600, however it's just barely able to handle the extra overhead of gdb, and has forced me to shut down the terminal on a couple of occasions.  SSH is a good idea, although I haven't managed to network my Z yet.  Incidentally, the bug has turned out to be really weird -- just before the segfault, execution jumps into the middle of a function my program didn't even call, so I can only assume I'm having cross-compilation issues of some kind.