NetBSD Problem Report #46490

From martin@duskware.de  Mon May 28 10:48:02 2012
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 2FC4763B882
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 28 May 2012 10:48:02 +0000 (UTC)
Message-Id: <20120528104802.2FC4763B882@www.NetBSD.org>
Date: Mon, 28 May 2012 10:48:02 +0000 (UTC)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@gnats.NetBSD.org
Subject: libexecinfo only wokrs on amd64
X-Send-Pr-Version: 3.95

>Number:         46490
>Category:       toolchain
>Synopsis:       libexecinfo only wokrs on amd64
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    toolchain-manager
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon May 28 10:50:00 +0000 2012
>Closed-Date:    Sat Feb 01 19:03:05 +0000 2014
>Last-Modified:  Sat Feb 01 19:03:05 +0000 2014
>Originator:     Martin Husemann
>Release:        NetBSD 6.99.7
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD thirdstage.duskware.de 6.99.7 NetBSD 6.99.7 (MODULAR) #0: Sun May 27 23:21:43 CEST 2012 martin@night-porter.duskware.de:/usr/src-clean/sys/arch/sparc64/compile/MODULAR sparc64
Architecture: sparc64
Machine: sparc64
>Description:

The new libexecinfo seems to be implemented using a technique that is gcc
specific and only works (with default compile flags) on amd64, where
.eh_frame_hdr and .eh_frame sections are generated by default.n

The corresponding test case seems to fail everywhere else right now.

The _Unwind_Backtrace() call calls back into "tracer" once, the t->n value
is still (size_t)~0U so this frame is skipped, then unwinding terminates
with reason 5 (end of stack) and zero frames are returned.

>How-To-Repeat:
Run t_backtrace for example on sparc64.

>Fix:
I am not sure this is fixable, may need some other technique.

>Release-Note:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/46490: libexecinfo only wokrs on amd64
Date: Mon, 28 May 2012 13:04:40 +0200

 A workaround may be to do add COPTS += -funwind-tables for all our
 in-tree libraries guarded by some MKEXECINFO or similar, but this would
 still require building pkgsrc stuff and the application in question
 with those flags as well. This could be a documented restriction.

 At least the test case could be made to work with this (only the testprogram
 and libexecinfo involved).

 Martin

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, toolchain-manager@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: toolchain/46490: libexecinfo only wokrs on amd64
Date: Mon, 28 May 2012 09:06:19 -0400

 On May 28, 10:50am, martin@NetBSD.org (martin@NetBSD.org) wrote:
 -- Subject: toolchain/46490: libexecinfo only wokrs on amd64

 | The new libexecinfo seems to be implemented using a technique that is gcc
 | specific and only works (with default compile flags) on amd64, where
 | .eh_frame_hdr and .eh_frame sections are generated by default.n

 I thought that using _Unwind_Foo should work on every arch.

 | The corresponding test case seems to fail everywhere else right now.
 | 
 | The _Unwind_Backtrace() call calls back into "tracer" once, the t->n value
 | is still (size_t)~0U so this frame is skipped, then unwinding terminates
 | with reason 5 (end of stack) and zero frames are returned.
 | 
 | >How-To-Repeat:
 | Run t_backtrace for example on sparc64.
 | 
 | >Fix:
 | I am not sure this is fixable, may need some other technique.

 Try USE_BUILTIN=yes in the Makefile.

 christos

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/46490: libexecinfo only wokrs on amd64
Date: Tue, 29 May 2012 10:11:03 +0200

 Setting USE_UNWIND=no does not help. The struct frameinfo chain is
 one call deep:

 Breakpoint 2, backtrace (trace=0xc, len=1086333120) at builtin.c:56
 56      {
 (gdb) n
 58              void *stack = &stack;
 (gdb) 
 56      {
 (gdb) 
 60              for (size_t i = 0; i < len; i++) {
 (gdb) 
 57              const struct frameinfo *frame = __builtin_frame_address(0);
 (gdb) 
 61                      if ((const void *)frame BELOW stack)
 (gdb) print stack
 $5 = (void *) 0xffffffffffffb488
 (gdb) print frame
 $6 = (const struct frameinfo *) 0xffffffffffffb490
 (gdb) print *frame
 $7 = {next = 0xffffffffffffb550, return_address = 0x0}
 (gdb) print *frame->next
 $8 = {next = 0x0, return_address = 0x0}

 Info gcc says:

      On some machines it may be impossible to determine the frame
      address of any function other than the current one; in such cases,
      or when the top of the stack has been reached, this function will
      return `0' if the first frame pointer is properly initialized by
      the startup code.

 So this does not seem like the way forward either, though it probably will
 help i386.


 Martin

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/46490: libexecinfo only wokrs on amd64
Date: Wed, 30 May 2012 00:56:05 +0200

 Intererstingly...
 at least on sparc64, compiling both libexecinfo and the test with
 either -funwind-tables or -fexceptions does not make the test case work.

 Martin

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, toolchain-manager@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, martin@NetBSD.org
Cc: 
Subject: Re: toolchain/46490: libexecinfo only wokrs on amd64
Date: Tue, 29 May 2012 19:03:49 -0400

 On May 29, 11:00pm, martin@duskware.de (Martin Husemann) wrote:
 -- Subject: Re: toolchain/46490: libexecinfo only wokrs on amd64

 | The following reply was made to PR toolchain/46490; it has been noted by GNATS.
 | 
 | From: Martin Husemann <martin@duskware.de>
 | To: gnats-bugs@NetBSD.org
 | Cc: 
 | Subject: Re: toolchain/46490: libexecinfo only wokrs on amd64
 | Date: Wed, 30 May 2012 00:56:05 +0200
 | 
 |  Intererstingly...
 |  at least on sparc64, compiling both libexecinfo and the test with
 |  either -funwind-tables or -fexceptions does not make the test case work.

 But does the test fail completely, or does it produce a different result?
 Did you compile csu with  -funwind-tables?

 christos

From: Martin Husemann <martin@duskware.de>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@NetBSD.org
Subject: Re: toolchain/46490: libexecinfo only wokrs on amd64
Date: Wed, 30 May 2012 01:08:37 +0200

 On Tue, May 29, 2012 at 07:03:49PM -0400, Christos Zoulas wrote:
 > But does the test fail completely, or does it produce a different result?
 > Did you compile csu with  -funwind-tables?

 The backtrace is empty (0 pointers returned), so the test fails completely.
 I did not recompile csu with different flags.

 Martin

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/46490 CVS commit: src/tests/lib/libexecinfo
Date: Wed, 30 May 2012 06:01:22 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed May 30 06:01:22 UTC 2012

 Modified Files:
 	src/tests/lib/libexecinfo: t_backtrace.c

 Log Message:
 Skip test on non-amd64 machines for now, pointing to PR 46490.


 To generate a diff of this commit:
 cvs rdiff -u -r1.2 -r1.3 src/tests/lib/libexecinfo/t_backtrace.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->closed
State-Changed-By: martin@NetBSD.org
State-Changed-When: Sat, 01 Feb 2014 19:03:05 +0000
State-Changed-Why:
should be fixed


>Unformatted:

Home	PR Database Search