[PATCH] tile: fix DWARF bug in clone() for created thread

[PATCH] tile: fix DWARF bug in clone() for created thread

[Chris Metcalf]

  [David - this is pretty low risk (just adds one DWARF CFI directive),
  but also fixes a pretty minor bug.  So your call as to whether I should
  wait for 2.18 to commit.]

Previously, we would see a bad frame in the gdb backtrace output, e.g.:

  (gdb) bt
  #0  foo () at foo.c:5
  #1  0x000000aaaab68ee8 in start_thread () from /lib/libpthread.so.0
  #2  0x000000aaaad01c88 in clone () from /lib/libc.so.6
  #3  0x0000000000000000 in ?? ()

With this change the bogus frame #3 is gone and we have the
same output as x86 does for the same program.

2012-12-14  Chris Metcalf  <cmetcalf@tilera.com>

	* sysdeps/unix/sysv/linux/tile/nptl/clone.S: Fix DWARF info.

diff --git a/ports/sysdeps/unix/sysv/linux/tile/nptl/clone.S b/ports/sysdeps/unix/sysv/linux/tile/nptl/clone.S
index de4fa13..27592cc 100644
--- a/ports/sysdeps/unix/sysv/linux/tile/nptl/clone.S
+++ b/ports/sysdeps/unix/sysv/linux/tile/nptl/clone.S
@@ -160,6 +160,8 @@ ENTRY (__clone)
    r32: the user function pointer  */
 
 .Lthread_start:
+	cfi_def_cfa_offset (FRAME_SIZE)
+	cfi_undefined (lr)
 	/* Check and see if we need to reset the PID, which we do if
 	   CLONE_THREAD isn't set, i.e. we're not staying in the thread group.
 	   If CLONE_VM is set, we're doing some kind of thread-like clone,
@@ -167,7 +169,6 @@ ENTRY (__clone)
 	   in getpid().  Otherwise (if CLONE_VM isn't set), it's a
 	   fork-like clone, and we go ahead and write the cached values
 	   from the true system pid (retrieved via __NR_getpid syscall).  */
-	cfi_def_cfa_offset (FRAME_SIZE)
 #ifdef __tilegx__
 	{
 	 moveli r0, hw1_last(CLONE_VM)
-- 
1.7.10.3

Re: [PATCH] tile: fix DWARF bug in clone() for created thread

[Chris Metcalf]

On 12/14/2012 10:46 AM, Chris Metcalf wrote:
>   [David - this is pretty low risk (just adds one DWARF CFI directive),
>   but also fixes a pretty minor bug.  So your call as to whether I should
>   wait for 2.18 to commit.]

Ping?  I like the idea of fixing this in 2.17 just because customers tend to go "WTF?" when they see this in the debugger output.

> Previously, we would see a bad frame in the gdb backtrace output, e.g.:
>
>   (gdb) bt
>   #0  foo () at foo.c:5
>   #1  0x000000aaaab68ee8 in start_thread () from /lib/libpthread.so.0
>   #2  0x000000aaaad01c88 in clone () from /lib/libc.so.6
>   #3  0x0000000000000000 in ?? ()
>
> With this change the bogus frame #3 is gone and we have the
> same output as x86 does for the same program.
>
> 2012-12-14  Chris Metcalf  <cmetcalf@tilera.com>
>
> 	* sysdeps/unix/sysv/linux/tile/nptl/clone.S: Fix DWARF info.
>
> diff --git a/ports/sysdeps/unix/sysv/linux/tile/nptl/clone.S b/ports/sysdeps/unix/sysv/linux/tile/nptl/clone.S
> index de4fa13..27592cc 100644
> --- a/ports/sysdeps/unix/sysv/linux/tile/nptl/clone.S
> +++ b/ports/sysdeps/unix/sysv/linux/tile/nptl/clone.S
> @@ -160,6 +160,8 @@ ENTRY (__clone)
>     r32: the user function pointer  */
>  
>  .Lthread_start:
> +	cfi_def_cfa_offset (FRAME_SIZE)
> +	cfi_undefined (lr)
>  	/* Check and see if we need to reset the PID, which we do if
>  	   CLONE_THREAD isn't set, i.e. we're not staying in the thread group.
>  	   If CLONE_VM is set, we're doing some kind of thread-like clone,
> @@ -167,7 +169,6 @@ ENTRY (__clone)
>  	   in getpid().  Otherwise (if CLONE_VM isn't set), it's a
>  	   fork-like clone, and we go ahead and write the cached values
>  	   from the true system pid (retrieved via __NR_getpid syscall).  */
> -	cfi_def_cfa_offset (FRAME_SIZE)
>  #ifdef __tilegx__
>  	{
>  	 moveli r0, hw1_last(CLONE_VM)

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

Re: [PATCH] tile: fix DWARF bug in clone() for created thread

[David Miller]

From: Chris Metcalf <cmetcalf@tilera.com>
Date: Fri, 21 Dec 2012 15:14:05 -0500

> On 12/14/2012 10:46 AM, Chris Metcalf wrote:
>>   [David - this is pretty low risk (just adds one DWARF CFI directive),
>>   but also fixes a pretty minor bug.  So your call as to whether I should
>>   wait for 2.18 to commit.]
> 
> Ping?  I like the idea of fixing this in 2.17 just because customers
> tend to go "WTF?" when they see this in the debugger output.

Ok.