From dinoex@net2.dinoex.sub.org  Sun Jul  6 11:32:59 1997
Received: from mail.Contrib.Com (mail.Contrib.Com [194.77.12.8])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA01131
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 6 Jul 1997 11:32:57 -0700 (PDT)
Received: from net2.dinoex.sub.org (net2.dinoex.sub.de [193.203.172.193])
          by mail.Contrib.Com (8.8.4/8.8.4) with SMTP
	  id UAA10805 for <freebsd.org!FreeBSD-gnats-submit>; Sun, 6 Jul 1997 20:32:48 +0200 (MET DST)
Received: by net2.dinoex.sub.org (Smail3.1.29.1 #1)
	id m0wkwBs-000DzsC; Sun, 6 Jul 97 20:37 CEST
Message-Id: <m0wkwBs-000DzsC@net2.dinoex.sub.org>
Date: Sun, 6 Jul 97 20:37 CEST
From: dinoex@net2.dinoex.sub.org
Reply-To: dirk.meyer@dinoex.sub.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: gdb stackframe in static library shows not the calling function
X-Send-Pr-Version: 3.2

>Number:         4042
>Category:       gnu
>Synopsis:       gdb stackframe in static library shows not the calling function
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    obrien
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Jul  6 11:40:01 PDT 1997
>Closed-Date:    Fri Nov 10 09:19:37 PST 2000
>Last-Modified:  Fri Nov 10 09:20:01 PST 2000
>Originator:     Dirk Meyer
>Release:        FreeBSD 2.2.1-RELEASE i386
>Organization:
privat
>Environment:

	

>Description:

	
	gdb doesn't sho the calling stack
	in a function of a static linked library.
	if an error ocurrs in the function,
	ther is no information of the calling stack frame.

>How-To-Repeat:

	
	compile the folowing sample, run it under gdb,
	show the calling stack.
/*
 st.c

 gcc: 2.7.2.1
 gdb: GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc.

 cc st.c -static -g
 gdb a.out 

GDB is free software and you are welcome to 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.
 GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc...
 (gdb) run
 Starting program: /var/spool/dinoex/hub/a.out 
 a

 Program received signal SIGSEGV, Segmentation fault.
 0x11b5 in strlen ()
 (gdb) bt
 #0  0x11b5 in strlen ()
 #1  0x0 in ?? ()
 (gdb) quit
 The program is running.  Quit anyway (and kill it)? (y or n) y
*/

#include <string.h>

void main( void )
{
	size_t len;

	printf( "a\n" );
	len = strlen( NULL );
	printf( "b\n" );
}

/* EOF */

>Fix:

	
	none.

>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: dinoex@net2.dinoex.sub.org, FreeBSD-gnats-submit@FreeBSD.ORG
Cc:  Subject: Re: gnu/4042: gdb stackframe in static library shows not the calling function
Date: Mon, 7 Jul 1997 07:09:19 +1000

 >	gdb doesn't sho the calling stack
 >	in a function of a static linked library.
 >	if an error ocurrs in the function,
 >	ther is no information of the calling stack frame.
 
 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
 when there is only one or two frames.  All functions written in assembler
 have this problem.
 
 Bruce

From: Peter Wemm <peter@spinner.dialix.com.au>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-gnats-submit@hub.freebsd.org
Subject: Re: gnu/4042: gdb stackframe in static library shows not the calling function 
Date: Mon, 07 Jul 1997 13:06:36 +0800

 Bruce Evans wrote:
 >  >	gdb doesn't sho the calling stack
 >  >	in a function of a static linked library.
 >  >	if an error ocurrs in the function,
 >  >	ther is no information of the calling stack frame.
 >  
 >  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
 >  when there is only one or two frames.  All functions written in assembler
 >  have this problem.
 
 How much overhead will it be to do the stack frame linkage correctly?  As 
 I see it, it'll mean adding something like this:
 
 ENTRY(foo)
 +	pushl %ebp
 +	movl %esp,%ebp
 	....
 +	leave
 	ret
 .. to each assembler function.  Is this price too high to pay?  In some 
 cases (ie: where the function doesn't make other calls, eg: strlen()), it 
 *might* be simplified further (assuming what I've done is correct):
 ENTRY(foo)
 +	pushl %ebp
 	....
 +	addl $4,%esp	(or: popl %ebp, whichever is quicker)
 	ret
 
 >  Bruce
 
 Cheers,
 -Peter
 

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
State-Changed-From-To: open->suspended 
State-Changed-By: joerg 
State-Changed-When: Sun Oct 12 14:25:06 MEST 1997 
State-Changed-Why:  

I don't see that anybody's going to handle this at all.  The 
audit-trail contains enough of discussion for why the problem appears. 
Responsible-Changed-From-To: freebsd-bugs->obrien 
Responsible-Changed-By: obrien 
Responsible-Changed-When: Mon Jul 10 02:48:42 PDT 2000 
Responsible-Changed-Why:  

http://www.freebsd.org/cgi/query-pr.cgi?pr=4042 
State-Changed-From-To: suspended->closed 
State-Changed-By: obrien 
State-Changed-When: Fri Nov 10 09:19:37 PST 2000 
State-Changed-Why:  
This isssue is really OBE at this point. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=4042 
>Unformatted:
