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

["Lu, Hongjiu" <hongjiu.lu@intel.com>]

It may be a gcc/glibc thing. In this bug report:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124646

there is a testcase. Gdb 6.1 is even worse than gdb in Fedora Core 2. It
tries to unwind stack until running out of space. If you have a patch, I
can give it a try.


H.J. Lu
Intel Corporation

>-----Original Message-----
>From: Mark Kettenis [ mailto:kettenis@chello.nl ]
>Sent: Friday, May 28, 2004 2:47 PM
>To: Lu, Hongjiu
>Cc: gdb-patches@sources.redhat.com
>Subject: Re: HACK: Fix the backstrace for Linux/x86-64.
>
>   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