This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Fwd: Unwinding through `no return'?]


FYI,

Andrew
--- Begin Message --- 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



--- End Message ---

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]