This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: HACK: Fix the backstrace for Linux/x86-64.
- From: Mark Kettenis <kettenis at chello dot nl>
- To: hongjiu dot lu at intel dot com
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 28 May 2004 23:46:32 +0200 (CEST)
- Subject: Re: HACK: Fix the backstrace for Linux/x86-64.
- References: <20040528012818.GA7420@lucon.org>
Date: Thu, 27 May 2004 18:28:18 -0700
From: "H. J. Lu" <hongjiu.lu@intel.com>
Should we put "hacks" into GDB?
I am using this hack to work around the backstrace bug on x86-64. Right
now we are getting:
(gdb) bt
#0 foo () at foo.c:4
During symbol reading, Incomplete CFI data; unspecified registers at
0x0000000000400490.
#1 0x00000034d4b1c48a in __libc_start_main () from
/lib64/tls/libc.so.6
#2 0x00000000004003ea in _start ()
#3 0x0000007fbffff8a8 in ?? ()
#4 0x000000000000001c in ?? ()
This is weird. Where is main()? I think that's the problem, which
should be solved.
2004-05-27 H.J. Lu <hongjiu.lu@intel.com>
* amd64-tdep.c (amd64_frame_cache): Add outermost_p.
(amd64_alloc_frame_cache): Clear outermost_p.
(amd64_analyze_prologue): Set outermost_p for "xor %rbp,%rbp"
to mark the outermost frame.
(amd64_frame_cache): Return if outermost_p is set.
Clever, however, I'm not convinced this is a good idea. The fact that
the Linux startup code clears %rbp is utterly pointless:
.text
.globl _start
.type _start,@function
_start:
/* Clear the frame pointer. The ABI suggests this be done, to mark
the outermost frame obviously. */
xorq %rbp, %rbp
The ABI doesn't suggest that at all (at least I can't find it) and
usage of %rbp as a frame pointer is optional, and certainly not the
default. This was probably just copied from the i386 code, and should
be removed. Then your "hack" doesn't work anymore.
Personaly I don't think the fact that the frame chain isn't properly
terminated is a big problem. It only manifests itself if you'r
backtracing from within the startup code. People doing so should now
what they're doing. However, other people might think differently.
In that case we should think about enabling the inside_entry_func()
test.
Mark