This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
Re: gdb/2171: No backtrace generated on amd64
- From: Daniel Jacobowitz <drow at false dot org>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 17 Sep 2006 22:58:02 -0000
- Subject: Re: gdb/2171: No backtrace generated on amd64
- Reply-to: Daniel Jacobowitz <drow at false dot org>
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