[Fwd: Unwinding through `no return'?]

[Fwd: Unwinding through `no return'?]

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 13 bytes --]

FYI,

Andrew

[-- Attachment #2: Unwinding through `no return'? --]
[-- Type: message/rfc822, Size: 3421 bytes --]

From: Andrew Cagney <ac131313@redhat.com>
To: Dwarf 2 List <dwarf2@els.sgi.com>
Subject: Unwinding through `no return'?
Date: Wed, 13 Aug 2003 00:52:35 -0400
Message-ID: <3F39C413.8070201@redhat.com>

Hello,

A clasic function call sequence will look something look like:

	push arguments
	call func
	pop arguments <- RA

When a compiler determines that the function won't return it might 
convert it into:

	push arguments
	call func
	<- RA

I'm trying to understand how CFI should handle this.

The problem I've encountered is that the RA provided by func's CFI could 
end up pointing at totally unrelated instruction  For instance the code:

	bar()
	{
	  func () // no return
	}

	baz ()
	{
	  ...

could become:

	bar:
		push arguments
		call func
	baz:
		prologue of baz <- RA

leading to a bogus unwind (other more edgy cases occure when the call is 
at the end of a block - this one is easier to explain :-).

One `work around' is recognize that func was reached via a call 
instruction and then use RA-1 to locate the CFI for the function vis:

	bar:
		push arguments
		call func <- (RA-1)
	baz:
		prologue of baz

That way the address at least falls on an instruction related to the 
call sequence.  Is this accepted best-pratice, or is there a more robust 
way of handling this?  I can see, although off the top of my head I 
can't think of, an ISA that may need different CFI info for the two 
cases of:

- about to execute ``call func''
- unwinding back through the ``call func'' instruction

and the above won't allow that.

comments?
Andrew

Re: [Fwd: Unwinding through `no return'?]

[Michael Elizabeth Chastain]

Three comments, kinda superficial:

Sometimes the caller will be in code with no debug info,
such as library code.  RA-1 would be good there.

Look at the case where the operating system delivers a signal and sets
up a sigreturn frame.  In that case, a return address on a stack
really does point to the first instruction of a function (__restore
on my red hat linux 8 box).  RA-1 would be bad there.

Someone, maybe rth?, mentioned that on some architectures,
the ABI requires a nop instruction after a noreturn call.
If we ask gcc to do something like that in all cases it might
make our job easier.

Michael C

Re: [Fwd: Unwinding through `no return'?]

[Andrew Cagney]

> Three comments, kinda superficial:
> 
> Sometimes the caller will be in code with no debug info,
> such as library code.  RA-1 would be good there.
> 
> Look at the case where the operating system delivers a signal and sets
> up a sigreturn frame.  In that case, a return address on a stack
> really does point to the first instruction of a function (__restore
> on my red hat linux 8 box).  RA-1 would be bad there.

FYI, I've already sent a follow up expanding on this.

> Someone, maybe rth?, mentioned that on some architectures,
> the ABI requires a nop instruction after a noreturn call.
> If we ask gcc to do something like that in all cases it might
> make our job easier.

That matches one of the responses:

> Andrew:
> 
> We also encountered this problem, where the call's return address actually
> pointed to the first instruction of a subsequent routine, because the call
> was known never to return.  We were leery of changing the unwinder always to
> back up because of the issue you raised, where a normal function call might
> need different CFI before and after the call.  I don't know of a real world
> situation where that happens, but that doesn't mean there isn't one, and I'd
> hate to break it.  Our tail-wagging-dog solution was to emit an extra
> instruction after the call that never returns.  On Pentium, for instance,
> ud2.  Then that extra instruction's address was the return address and it had
> CFI appropriate for the calling routine.
> 
> -- Todd Allen Concurrent Computer Corporation 

But it won't fly when the compiler is trying to optimize for space.

Andrew