NetBSD Problem Report #4590

Received: (qmail 19182 invoked from network); 28 Nov 1997 01:59:16 -0000
Message-Id: <199711280158.RAA18471@Reno.DSG.Stanford.EDU>
Date: Thu, 27 Nov 1997 17:58:36 -0800 (PST)
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Reply-To: jonathan@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: gdb on pmax cannot handle stripped binaries
X-Send-Pr-Version: 3.95

>Number:         4590
>Category:       toolchain
>Synopsis:       stack traceback fails on stripped binaries.
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    toolchain-manager
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Nov 27 18:05:01 +0000 1997
>Closed-Date:    Mon Aug 21 19:19:28 +0000 2017
>Last-Modified:  Mon Aug 21 19:19:28 +0000 2017
>Originator:     Jonathan Stone
>Release:        1.3_ALPHA
>Organization:

>Environment:

System: NetBSD Reno.DSG.Stanford.EDU 1.3_ALPHA NetBSD 1.3_ALPHA (GENERIC) #0: Sat Nov 22 16:32:51 PST 1997 jonathan@Reno.DSG.Stanford.EDU:/reno/compile/GENERIC pmax


>Description:

  gdb on pmaxes cannot handles tatic binaries.
  Even a  hex-address stacktrace fails.
  GDB reports that the heuristic fencepost on its PC search is
  exceeded and gives up.

  This  used to work with stock FSF gdb 4.16.

>How-To-Repeat:

Get a stripped static binary to coredump.  (early 1.3_ALPHA sysinst on
a large scree was a good candidate).  Ask for a stack traceback and
Observe the `heuristic fencepost exceeded' warning.

I'm just guessing but it looks like the PC that gdb is getting from
the coredump is wrong.

Stack traceback of live inferiors (even when stripped) used to work on
the pre-integrated gdb 4.16 (and 4.15) code shipped with NetBSD/pmax
snapshots.

>Fix:

None known.
>Release-Note:
>Audit-Trail:

From: [unknown, scrambled by gnats, restored much later by dholland]

 Verified this still exists on 1.6-current:

 Program terminated with signal 6, Aborted.

 warning: Warning: GDB can't find the start of the function at 0x40e4a4.

    GDB is unable to find the start of the function at 0x40e4a4
 and thus can't determine the size of that function's stack frame.
 This means that GDB may be unable to access that stack frame, or
 the frames below it.
    This problem is most likely caused by an invalid program counter or
 stack pointer.
    However, if you think GDB should simply search farther back
 from 0x40e4a4 for code which looks like the beginning of a
 function, you can increase the range of the search using the `set
 heuristic-fence-post' command.

 The core file itself is fine. gdb simply can't interpet the stripped
 binary as gdb'ing against a non-stripped binary and same core gives:

 Program terminated with signal 6, Aborted.
 #0  0x0040e4a4 in kill ()
 (gdb) bt
 #0  0x0040e4a4 in kill ()
 #1  0x0040ce00 in abort ()
 #2  0x004008c0 in bar ()
 #3  0x00400850 in foo ()
 #4  0x00400804 in main ()
 #5  0x004002f0 in _start ()

Responsible-Changed-From-To: bin-bug-people->toolchain-manager 
Responsible-Changed-By: gnats 
Responsible-Changed-When: Tue Feb 12 00:51:34 PST 2002 
Responsible-Changed-Why:  
There is now a "toolchain-manager" which is the proper default role 
account for handling problem reports in the toolchain category. 

State-Changed-From-To: open->feedback 
State-Changed-By: mrg 
State-Changed-When: Fri Apr 2 07:28:09 UTC 2004 
State-Changed-Why:  
hi jonathan.  can you see if this is still a problem with 2.0/-current? 
GDB 5.3 may have fixed it... 
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: toolchain/4590: gdb on pmax cannot handle stripped binaries
Date: Sat, 8 Mar 2008 08:25:43 +0000

 I've seen this problem with stock FSF gdb as recently as 6.0 (haven't
 tried later) - it is mips-specific. The problem is not that it's
 getting wrong addresses from the core file but that it does something
 stupid when it has no symbols.

 Anyone want to try gdb 6.5? It is easy to reproduce if you have a
 mips; copy /bin/sleep, strip it, run it in gdb, hit ^C...
 -- 
 David A. Holland
 dholland@netbsd.org

State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 04 May 2008 02:25:54 +0000
State-Changed-Why:
This does not need to be in feedback, but if someone would like to test the
latest/greatest gdb on mips and report back, it might be vaguely useful.
Who knows, the problem might even be fixed...


State-Changed-From-To: open->suspended
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 04 May 2008 02:26:51 +0000
State-Changed-Why:
On reflection, this should probably be set to suspended, not open, since
it'll need to be fixed upstream. Unless anyone *really* wants to dig into
gdb...


State-Changed-From-To: suspended->closed
State-Changed-By: mrg@NetBSD.org
State-Changed-When: Mon, 21 Aug 2017 19:19:28 +0000
State-Changed-Why:
this works in -current for me.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.