Problem debugging core dump in gdb 7.1 on Solaris x86_64

[Max Kaehn <slothman@electric-cloud.com>]

On a Solaris x86_64 machine:

tempest-solaris% uname -a
SunOS tempest-solaris 5.10 Generic_141445-09 i86pc i386 i86pc Solaris

with a gdb 7.1 configured thusly:

./configure  --build=x86_64-pc-solaris2.10 --host=x86_64-pc-solaris2.10 
--target=x86_64-pc-solaris2.10 
--prefix=/net/tools/gnu/gdb/7.1/i686_SunOS_64.5.10 
--with-mpfr=/net/tools/mpfr/2.4.1/i686_SunOS_64.5.10 
--with-gmp=/net/tools/gmp/4.3.1/i686_SunOS_64.5.10 
--with-tcl=/net/tools/tcl/8.6b1/i686_SunOS_64.5.10/lib 
--with-tk=/net/tools/tcl/8.6b1/i686_SunOS_64.5.10/lib --with-expat 
--with-libexpat-prefix=/net/tools/expat/2.0.1/i686_SunOS_64.5.10 
--with-curses --with-python=no --enable-tui  --enable-64bit 
--enable-64-bit-bfd 
--with-libiconv-prefix=/net/tools/libiconv/1.13.1/i686_SunOS_64.5.10 
--with-libintl-prefix=/net/tools/gnu/gettext/0.17/i686_SunOS_64.5.10 
--enable-targets=i686-pc-solaris2.10,x86_64-pc-solaris2.10

and built using gcc 4.3.4 configured for i686-pc-solaris2.10 (which 
generates functioning amd64 binaries when I build with -m64), I can get 
a reasonable stack trace from the core dump from a simple program 
("hello, world" + core dump):

GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-solaris2.10".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/slothman/Projects/goodbye...done.
[New LWP 1]
Reading symbols from 
/net/tools/util/i686_SunOS.5.10/lib/amd64/libstdc++.so.6...done.
Loaded symbols for /net/tools/util/i686_SunOS.5.10/lib/amd64/libstdc++.so.6
Reading symbols from /lib/amd64/libm.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /lib/amd64/libm.so.2
Reading symbols from 
/net/tools/util/i686_SunOS.5.10/lib/amd64/libgcc_s.so.1...done.
Loaded symbols for /net/tools/util/i686_SunOS.5.10/lib/amd64/libgcc_s.so.1
Reading symbols from /lib/amd64/libc.so.1...(no debugging symbols 
found)...done.
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
Loaded symbols for /lib/amd64/libc.so.1
Reading symbols from /lib/amd64/ld.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /lib/amd64/ld.so.1
Core was generated by `./goodbye'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000400d17 in main (argc=1, argv=0xfffffd7fffdff848)
     at goodbye.cpp:7
7           *p = 0;

but I've been unable to get a sensible stack trace out of a core dump 
from a more complex program:

tempest-solaris% /net/tools/gnu/gdb/7.1/i686_SunOS_64.5.10/bin/gdb 
/net/chronic2nas/emake-slothman-main/out/i686_SunOS_64.5.10/ecloud/agent/ecagent 
/net/chronic2nas/emake-slothman-main/logs-201006211902-solx2-ea2/core
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-solaris2.10".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from 
/net/chronic2nas/emake-slothman-main-201006211520/out/i686_SunOS_64.5.10/ecloud/agent/ecagent...done.
[New LWP 1]
[New LWP 2]
[New LWP 3]
[New LWP 4]
[New LWP 5]
Reading symbols from /usr/lib/amd64/ld.so.1...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/amd64/ld.so.1
Core was generated by `/opt/ecloud/i686_SunOS.5.10/bin/ecagent 
/opt/ecloud/i686_SunOS.5.10/bin/runagen'.
Program terminated with signal 11, Segmentation fault.
#0  0xfffffd7ffeac431c in ?? ()
(gdb) bt
#0  0xfffffd7ffeac431c in ?? ()
Cannot access memory at address 0xfffffd7fffdfed30
(gdb) thread 2
[Switching to thread 2 (LWP 2)]#0  0xfffffd7ffeb2c8fa in ?? ()
(gdb) bt
#0  0xfffffd7ffeb2c8fa in ?? ()
Cannot access memory at address 0xfffffd7ffe1f8dd8
(gdb) thread 3
[Switching to thread 3 (LWP 3)]#0  0xfffffd7ffeb27527 in ?? ()
(gdb) bt
#0  0xfffffd7ffeb27527 in ?? ()
Cannot access memory at address 0xfffffd7ffdfffd68
(gdb) thread 4
[Switching to thread 4 (LWP 4)]#0  0xfffffd7ffeb27527 in ?? ()
(gdb) bt
#0  0xfffffd7ffeb27527 in ?? ()
Cannot access memory at address 0xfffffd7ffde00e78
(gdb) thread 5
[Switching to thread 5 (LWP 5)]#0  0xfffffd7ffeb2c8fa in ?? ()
(gdb) bt
#0  0xfffffd7ffeb2c8fa in ?? ()
Cannot access memory at address 0xfffffd7ffdbffc58
(gdb) info sharedlibrary
From                To                  Syms Read   Shared Object Library
0xfffffd7fff3c1010  0xfffffd7fff3e614e  Yes (*)     /usr/lib/amd64/ld.so.1
(*): Shared library is missing debugging information.

ldd reports this binary pulls in about 30 shared libraries.  I can load 
ecagent, type "break main", get a line number for it, and step through 
the code when it's live, but I still haven't managed to get gdb to 
figure out the core dump.

Is anyone familiar with the arcana of Solaris x86?

Thanks,
Max