Subject: port-alpha/23996: gcc 3.3 code motion confuses ddb backtracing
To: None <gnats-bugs@gnats.netbsd.org>
From: None <nathanw@mit.edu>
List: netbsd-bugs
Date: 01/05/2004 18:42:37
>Number:         23996
>Category:       port-alpha
>Synopsis:       gcc 3.3 code motion confuses ddb backtracing
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    port-alpha-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 05 23:43:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     Nathan J. Williams
>Release:        NetBSD 1.6ZG
>Organization:
	Massachvsetts Institvte of Technology
>Environment:
System: NetBSD samsung-means-to-come 1.6ZG NetBSD 1.6ZG (SAMSUNG) #43: Mon Dec 29 20:28:44 EST 2003  nathanw@marvin-the-martian.stuartst.com:/nbsd/src/sys/arch/alpha/compile/SAMSUNG alpha
Architecture: alpha
Machine: alpha
>Description:

The DDB tracing code in alpha/alpha/db_trace.c skims the instructions
of a routine from the entry point to the current PC in that routine,
building up a notion of the frame size and what registers are
saved. In particular, it looks for instructions of the form "lda
sp,-###(sp)" that adjust the stack.

Newer GCC can move code in a function "out of line" if it believes it
to be infrequently executed, such that the terminating 'ret'
instruction is not at the highest address of that function's code. For
example, it might rearrange:

-prologue
-A
-B
-C
-epilogue

into:

-prologue
-A
-C
-epilogue
-B

The problem is that if a code in B is in the stack trace,
decode_prologue() will find the stack-adjustment code in the epilogue
as well as the prologue, emitting "prologue botch" messages and
messing up the frame size such that the previous frame's RA is not
found.
	
>How-To-Repeat:

Set a DDB breakpoint in a piece of kernel code after that routine's
ret instruction, such as the instruction after the ret in
pmap_do_remove(). When the breakpoint is hit, type "t" and note the
"prologue botch" messages and the fact that the stack trace loops on
one routine.

>Fix:

The problem can be avoided by removing the "botch" messages and not
adjusting pi->pi_frame_size for positive stack offsets, but it loses
the botch protection. It might make more sense to ignore sp-adjusting
instructions that immediately precede a 'ret', if that sequence can be
guaranteed.

>Release-Note:
>Audit-Trail:
>Unformatted: