Re: HACK: Fix the backstrace for Linux/x86-64.

[Mark Kettenis <kettenis@chello.nl>]

   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