Re: gdb/2171: No backtrace generated on amd64

["Joe Hansche" <madcoder at gmail dot com>]

The following reply was made to PR gdb/2171; it has been noted by GNATS.

From: "Joe Hansche" <madcoder@gmail.com>
To: "Daniel Jacobowitz" <drow@false.org>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: gdb/2171: No backtrace generated on amd64
Date: Sat, 16 Sep 2006 01:15:28 -0600

 > Core dumps do not contain real symbol information.
 
 Sorry, I was just pointing out that it had the names of functions,
 which is what I would expect in the backtrace.
 
 > This is a shared library address.  Does info shared work?  It looks
 > like your system libraries are undebuggable, not the binary itself.
 
 (gdb) info shared
 No shared libraries loaded at this time.
 
 Which system libraries are you refering to?  I'm trying to get a
 backtrace from the php process.  The binary has debugging symbols.  Is
 there no way to get a backtrace with that?  What can I do to get a
 backtrace (either from shared libraries, or the php binary itself)?
 
 Thanks,
 Joe
 
 
 On 9/15/06, Daniel Jacobowitz <drow@false.org> wrote:
 > On Sat, Sep 16, 2006 at 12:05:32AM -0000, madcoder@gmail.com wrote:
 > > And the coredump has debugging symbols in it:
 >
 > Core dumps do not contain real symbol information.
 >
 > > > # gdb php core
 > > > GNU gdb 6.5
 > > > This GDB was configured as "x86_64-pc-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
 > > > Core was generated by `php -e test.php'.
 > > > Program terminated with signal 11, Segmentation fault.
 > > > #0  0x00002aaaac8d1e44 in ?? ()
 >
 > This is a shared library address.  Does info shared work?  It looks
 > like your system libraries are undebuggable, not the binary itself.
 >
 > --
 > Daniel Jacobowitz
 > CodeSourcery
 >