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: "Lu, Hongjiu" <hongjiu dot lu at intel dot com>
- To: "Mark Kettenis" <kettenis at chello dot nl>
- Cc: <gdb-patches at sources dot redhat dot com>
- Date: Fri, 28 May 2004 15:06:16 -0700
- Subject: RE: HACK: Fix the backstrace for Linux/x86-64.
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