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

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

[Lu, Hongjiu]

>        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.
>

FYI, the x86-64 ABI is based on the i386 ABI, which does suggest set
frame pointer to zero. I believe glibc is correct in doing so. Again if
you have a different patch, I will give it a try.


H.J.

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

[Lu, Hongjiu]

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

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

[H. J. Lu]

I am using this hack to work around the backstrace bug on x86-64. Right
now we are getting:

[hjl@gnu-64b bt]$ gdb a.out
GNU gdb 6.1.0.90_2004-05-27-cvs
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "x86_64-unknown-linux-gnu"...Using host
libthread_db library "/lib64/tls/libthread_db.so.1".
 
Setting up the environment for debugging gdb.
Function "internal_error" not defined.
Function "info_command" not defined.
.gdbinit:8: Error in sourced command file:
No breakpoint number 0.
(gdb) b foo
Breakpoint 1 at 0x400490: file foo.c, line 4.
(gdb) r
Starting program: /export/home/hjl/bugs/gdb/bt/a.out
 
Breakpoint 1, foo () at foo.c:4
4         printf ("hello\n");
(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 ?? ()
#5  0x0000000000000001 in ?? ()
#6  0x0000007fbffffabd in ?? ()
#7  0x0000000000000000 in ?? ()
#8  0x0000007fbffffae0 in ?? ()
#9  0x0000007fbffffafe in ?? ()
#10 0x0000007fbffffb17 in ?? ()
#11 0x0000007fbffffb26 in ?? ()
#12 0x0000007fbffffb31 in ?? ()
#13 0x0000007fbffffb49 in ?? ()
#14 0x0000007fbffffb5d in ?? ()
#15 0x0000007fbffffb86 in ?? ()
#16 0x0000007fbffffd49 in ?? ()
#17 0x0000007fbffffd55 in ?? ()
#18 0x0000007fbffffd68 in ?? ()
#19 0x0000007fbffffe57 in ?? ()
#20 0x0000007fbffffe6d in ?? ()
#21 0x0000007fbffffe8e in ?? ()
#22 0x0000007fbffffe9f in ?? ()
---Type <return> to continue, or q <return> to quit---





H.J.
----
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.

--- gdb/amd64-tdep.c.bt	2004-05-21 14:55:30.000000000 -0700
+++ gdb/amd64-tdep.c	2004-05-27 18:17:56.259080915 -0700
@@ -674,7 +674,10 @@ struct amd64_frame_cache
   CORE_ADDR saved_sp;
 
   /* Do we have a frame?  */
-  int frameless_p;
+  unsigned int frameless_p : 1;
+
+  /* Is this the outermost frame?  */
+  unsigned int outermost_p : 1;
 };
 
 /* Allocate and initialize a frame cache.  */
@@ -701,6 +704,8 @@ amd64_alloc_frame_cache (void)
   /* Frameless until proven otherwise.  */
   cache->frameless_p = 1;
 
+  cache->outermost_p = 0;
+
   return cache;
 }
 
@@ -714,7 +719,13 @@ amd64_alloc_frame_cache (void)
       movq %rsp, %rbp   0x48 0x89 0xe5
 
    Any function that doesn't start with this sequence will be assumed
-   to have no prologue and thus no valid frame pointer in %rbp.  */
+   to have no prologue and thus no valid frame pointer in %rbp.
+ 
+   Also handle
+ 
+     xor %rbp,%rbp	0x48 0x31 0xed
+
+   which marks the outermost frame.  */
 
 static CORE_ADDR
 amd64_analyze_prologue (CORE_ADDR pc, CORE_ADDR current_pc,
@@ -749,6 +760,13 @@ amd64_analyze_prologue (CORE_ADDR pc, CO
       cache->frameless_p = 0;
       return pc + 4;
     }
+  else if (op == 0x48 && current_pc > pc + 2)
+    {
+      /* Check for `xorl %rbp, %rbp'.  */
+      read_memory (pc + 1, buf, 2);
+      if (buf [0] == 0x31 && buf [1] == 0xed)
+	cache->outermost_p = 1;
+    }
 
   return pc;
 }
@@ -788,6 +806,9 @@ amd64_frame_cache (struct frame_info *ne
   if (cache->pc != 0)
     amd64_analyze_prologue (cache->pc, frame_pc_unwind (next_frame), cache);
 
+  if (cache->outermost_p)
+    return cache;
+
   if (cache->frameless_p)
     {
       /* We didn't find a valid frame.  If we're at the start of a

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

[Mark Kettenis]

   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