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]

Re: dwarf-frame.c question


Andrew Cagney <ac131313@redhat.com> writes:
> Discussed this with AlexO (of gcc).  Let us ruin your day.
> 
> This problem can occure even without recursion.  Consider the C snippet:
> 
> foo ()
> {
> 	if (i)
> 	  abort (with, lots, of parameters)
> 	do; normal; stuff;
> }
> 
> it can be turned into:
> 
> 	branch !i, 1:
> 	push with
> 	push lots
> 	push of
> 	push parameters
> 	call abort
> 1:
> 	do
> 	normal
> 	stuff
> 
> The return address can end up pointing at the ``do'' / 1: line and
> that's CFI info is definitly not correct for unwinding from abort().

It's worth pointing out that this problem is not possible to solve in
general.  If the compiler knows that a given call will never return,
it would be completely correct for it to trash the stack, overwrite
its saved return address, etc. before making the call.  Since the
older frames will never be used, they're dead, and code that makes
them unfindable is just as correct as code which trashes the value of
a dead variable.

The only reason it's possible to generate CFI at all in the normal
case is that the function itself needs to return, so the information
must be there somewhere.  Where that precondition doesn't hold,
unwinding is only possible when the compiler is lazy.  :)


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