I had host and target (our target arch is mips64octeon, and target os is 2.6.10_mvl401) version gdb both with the same configuration --target=mips64octeon-montavista-linux. The mips64_octeon_be-gdb is the host version gdb coming from vender's cross-compiler toolchain, it is also configured with --host=i686-pc-linux-gnu.
Whenever target crashed and core file generated, we can get into target os shell later, use the target/native gdb to open the binary/executable with the core file. In the case, target gdb works fine, it always decodes the trace frames completely and correctly. But question comes when we transfer the target binary (aware of its targetted to different arch) and core file out to cross-compiling machine (i686-pc-linux-gnu, 2.4.21-32.0.1.ELsmp i686), we find the mips64_octeon_be-gdb can't produce a complete back trace at all. We also tried the same test on different host machine (e.g. 2.6.9-42.7.ELsmp i686), problem keeps the same, after the first frame decoded, it (the cross version gdb - mips64_octeon_be-gdb) always complains with "Cannot access memory at address 0xXYZ". Assumption is that "mips64_octeon_be-gdb" (--host=i686-pc-linux-gnu) as a cross-platform version gdb, it should at least be able to open up core file with target binary properly even on host machine for offline debug (mainly for "bt" purpose). Any good idea on how to resolve this problem? Thanks! ~/coredump/sci:27> mips64_octeon_be-gdb sci.bin core..181 GNU gdb 6.3 (MontaVista 6.3-20.0.88.0702529 2007-01-31) Copyright 2004 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=mips64octeon-montavista-linux"... warning: exec file is newer than core file. Core was generated by `/sci/sci.bin'. Program terminated with signal 6, Aborted. #0 0x10013388 in cache_dist_stats () at soft_util.c:627 627 soft_util.c: No such file or directory. in soft_util.c (gdb) bt #0 0x10013388 in cache_dist_stats () at soft_util.c:627 Cannot access memory at address 0x30 (gdb) info reg zero at v0 v1 R0 0000000000000000 0000000000000000 0000000000000000 0000000000000000 a0 a1 a2 a3 R4 0000000000000000 0000000000000000 0000000000000000 ffffffff81340000 a4 a5 a6 a7 R8 0000000000000005 000000000000003c 000000007ffac3c4 0000000000000001 t0 t1 t2 t3 R12 0000000000000800 0000000000000000 000000001fff7944 00000000103b7630 s0 s1 s2 s3 R16 0000000000000000 0000000000000000 0000000000000000 ffffffff80000010 s4 s5 s6 s7 R20 ffffffff811189d8 0000000000000000 00000000103c0238 00000000103c0238 t8 t9 k0 k1 R24 0000000000002000 00000000103c0000 00000000103c2000 00000000103c20f8 gp sp s8 ra R28 0000000000000001 000000001fff7da4 0000000000000000 0000000010013640 sr lo hi bad 0000000000000000 0000000000000000 00000000103b7630 000000001fff7990 cause pc 000000001fff7990 0000000010013388 (gdb) _______________________________________________ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb