From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Lu, Hongjiu" To: "Mark Kettenis" Cc: Subject: RE: HACK: Fix the backstrace for Linux/x86-64. Date: Fri, 28 May 2004 22:07:00 -0000 Message-id: X-SW-Source: 2004-05/msg00773.html 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" > >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 > > * 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