From owner-freebsd-bugs  Mon Jul  7 00:00:10 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id AAA29024
          for bugs-outgoing; Mon, 7 Jul 1997 00:00:10 -0700 (PDT)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id AAA28996;
          Mon, 7 Jul 1997 00:00:03 -0700 (PDT)
Date: Mon, 7 Jul 1997 00:00:03 -0700 (PDT)
Message-Id: <199707070700.AAA28996@hub.freebsd.org>
To: freebsd-bugs
Cc: 
From: Bruce Evans <bde@zeta.org.au>
Subject: Re: gnu/4042: gdb stackframe in static library shows not the calling function
Reply-To: Bruce Evans <bde@zeta.org.au>
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR gnu/4042; it has been noted by GNATS.

From: Bruce Evans <bde@zeta.org.au>
To: bde@zeta.org.au, peter@spinner.dialix.com.au
Cc: freebsd-gnats-submit@hub.freebsd.org
Subject: Re: gnu/4042: gdb stackframe in static library shows not the calling function
Date: Mon, 7 Jul 1997 16:50:56 +1000

 >>  This is caused by the function in the example (strlen) not having a frame
 >>  pointer.  The top frame or two gets lost.  The problem is most obvious
 
 >How much overhead will it be to do the stack frame linkage correctly?  As 
 >I see it, it'll mean adding something like this:
 
 Not much, unless you count source bloat.
 
 >ENTRY(foo)
 >+	pushl %ebp
 >+	movl %esp,%ebp
 >	....
 >+	leave
 >	ret
 
 "Correctly" requires ifdefs for -fomit-frame-pointer, -m486, etc. :-)
 
 Bruce