This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


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

Re: ARM problems with the exception unwinder


> 
> [ Andy, unfortunately your patch doesn't have any effect on this problem 
> (though it doesn't make things any worse)]
> 
> I've run into a problem with the exception unwinder on the ARM.  In a 
> nutshell, I can make it work for code with a stack frame, or I can make it 
> work for code without; but I can't make it work for both at the same time.
> 
> The problem is that when the stack-pointer is stored in the frame of the 
> callee of the function catching the throw, the unwind code updates the 
> value there and I must not adjust the stack-pointer by OFFSET when 
> returning from __throw/__rethrow.  However, if that function has not 
> stored the stack-pointer in its frame, then I must adjust the 
> stack-pointer by OFFSET.  The problem is, that I have no way of telling 
> which method to use when compiling __builtin_eh_return since there is 
> insufficient information available to make a dynamic choice.
> 

I've just been looking at execute_cfa_insn() in frame_dwarf2.c and I've no 
idea how it is supposed to work when the cfa reg is not the stack pointer, 
since it seems to completely ignore any adjustments to the cfa register.  
How is this code supposed to work when the cfa register changes from frame 
to frame?


      if (reg == state->s.cfa_reg)
	/* Don't record anything about this register; it's only used to
	   reload SP in the epilogue.  We don't want to copy in SP
	   values for outer frames; we handle restoring SP specially.  */;
      else

Surely the above is wrong when cfa_reg != SP.  I think this is the crux of 
the problems I am seeing on the ARM.

R.



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