gdb/2171: No backtrace generated on amd64

Daniel Jacobowitz
Sun Sep 17 22:58:00 GMT 2006

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

From: Daniel Jacobowitz <>
To: Joe Hansche <>
Subject: Re: gdb/2171: No backtrace generated on amd64
Date: Sun, 17 Sep 2006 18:48:00 -0400

 On Sat, Sep 16, 2006 at 02:36:52PM -0600, Joe Hansche wrote:
 > >Take a look with readelf -l at the php binary and the core file.
 > >The binary should have a DYNAMIC entry.  Do any of the LOAD entries for
 > >the core file cover that same address region?  If so, do they have
 > >non-zero values in FileSiz?
 > # readelf -l /usr/lib64/php5/bin/php | grep DYNAMIC
 >  DYNAMIC        0x0000000000535070 0x0000000000635070 0x0000000000635070
 > # readelf -l core
 > ...
 >  LOAD           0x0000000000053000 0x00002aaaab546000 0x0000000000000000
 >                 0x0000000000000000 0x0000000000064000  R E    1000
 >  LOAD           0x0000000000053000 0x00002aaaab5aa000 0x0000000000000000
 >                 0x0000000000000000 0x0000000000100000         1000
 >  LOAD           0x0000000000053000 0x00002aaaab6aa000 0x0000000000000000
 >                 0x0000000000006000 0x0000000000006000  RW     1000
 > ...
 > Would that be considered "covering the same region"?  There aren't any
 > entries that have identical values.  (the 3rd entry there, with RW,
 > has the non-zero FileSiz)
 Sorry, I wasn't clear enough - neither these nor your later
 off-list message are the right entries.  The first column is a physical
 file offset, and is not particularly interesting.  The intersting bit
 is the second column: virtual address, e.g. 0x0000000000635070.  Is
 that covered by any LOAD?
 > Would that be a specific kernel version, or something compiled into
 > the kernel, which breaks that?  If it's the kernel version, would you
 > happen to know which kernel is known to behave properly, or would you
 > know of anything that is known to cause this behavior when compiled
 > into the kernel?  I can compile a new kernel if you think it will make
 > a difference.
 It'd be a kernel version, but I don't remember which.  I think 2.6.15
 is far too new to have the problem, but I don't remember for sure.
 Daniel Jacobowitz

More information about the Gdb-prs mailing list