gdb/2171: No backtrace generated on amd64

Daniel Jacobowitz drow@false.org
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 <drow@false.org>
To: Joe Hansche <madcoder@gmail.com>
Cc: gdb-gnats@sources.redhat.com
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
 CodeSourcery



More information about the Gdb-prs mailing list