Re: Fix Sparc GDB regression

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Apr 05, 2002 at 07:03:26AM -0800, David S. Miller wrote:
> 
> If we had a function on Sparc and the last thing it did was call a
> noreturn attribute function we'd get something like this:
> 
> func1:
> 	...
> 	call	no_return_func
> 	 nop
> func2:
> 
> The standard way to get the caller's PC in a backtrace on this
> platform is to examine the %i7 register (%o7 for a leaf) in the
> current frame and add 8 bytes to it (which tells you where in the
> function the callee will start executing upon return).
> 
> Except because of the optimization the Sparc backend is performing
> above (not emitting the return instructions since they'll never
> be executed) the backtracer ends up seeing "%i7 + 8" as being
> the first instruction in func2.
> 
> There turns out to be a test that specifically triggers this case in
> the GDB testsuite.  Basically it amounts to a function which calls
> abort(), the test lets the abort() happen, and verifies that the
> backtrace looks sane.  In the bogus backtrace, the function calling
> abort() did not even get mentioned.
> 
> This is likely to confuse not only GDB, as any Sparc backtrace
> mechanism is going to fall victim to this.

Wouldn't it be better to really check if the last real instruction
(or dbr sequence) is a call? I'm afraid you'll emit nop even for
func1:
    ...
    b .L123
     do_something
func2:

> 2002-04-05  David S. Miller  <davem@redhat.com>
> 
> 	* config/sparc/sparc.c (sparc_nonflat_function_epilogue): If we
> 	are not going to emit return instructions, emit at least a nop
> 	for the sake of sane backtraces.

	Jakub