Re: [PATCH][SH] CFI directives patch

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

On Fri, 4 May 2012 10:29:14 -0700, Richard Henderson <rth@twiddle.net> wrote:
> On 05/04/12 00:03, Chung-Lin Tang wrote:
> >  5:
> > +	cfi_remember_state
> >  	rts
> >  	 mov.l	@r15+, r12
> > +	cfi_adjust_cfa_offset (-4)
> > +	cfi_restore (r12)
> > +	cfi_restore_state
> >  
> 
> This really has no effect.  All cfi operations at a given address are evaluated for a given pc.  This adjustment and restore are immediately over-ridden by the restore_state.
> 
> CFI operations are not well-defined inside delay slots, because in general the consumers have no insight as to how to differentiate the CFA state of the branch from the CFA state of the delay slot.  Within GCC, we avoid moving frame-related insns into a delay slot.  That's probably the safest resolution in this case.
> 
> Anything else would require that you can somehow teach the unwinder how asynchronous interrupts and delay slots interact (for SH at least).

In my understanding of the SH-4A Software Manual, and Kaz please correct
me if there's anything wrong, any delayed branch instruction forms an
inseparable unit with instruction in the branch-delay slot, and there is
no way to reach/inspect the intermediate state.  Thus, it is correct to
update the CFI after the delay-slot instruction.

I suppose that if GDB patches a break-point instruction (TRAPA) into the
delay slot (in case it does that at all; should check), this must result
in a ÂSlot Illegal Instruction ExceptionÂ.  And, I wonder what happens if
using the Linux kernel's single-stepping implementation with instead of
patching a TRAPA programs the User Break Controller.

Typically, updating the CFI after the delay-slot instructions following
unconditional branches will be pointless, as we will have branched
elsewhere by then, and left the current frame, so the control flow can
never reach past that point anyway.


GrÃÃe,
 Thomas

Attachment: pgp00000.pgp
Description: PGP signature