[Fwd: Unwinding through `no return'?]

[Andrew Cagney <ac131313@redhat.com>]

[-- 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