Re: [avr] gas support for cfi info

[Richard Henderson <rth at redhat dot com>]

On 02/17/2011 07:35 AM, Anitha Boyapati wrote:
> Can you please explain the logic behind the following lines in gcc patch:
> 
> 
> -         offset = -cfa_store.offset;
> +         if (GET_CODE (XEXP (dest, 0)) == POST_DEC)
> +           offset += -cfa_store.offset;
> +         else
> +           offset = -cfa_store.offset;

This is differentiating between pre-dec and post-dec.

		pre-dec		post-dec
before		stuff		stuff
		stuff	<-sp	trash	<-sp
		trash

after		stuff		stuff
		stuff		value
		value	<-sp	trash	<-sp

We've just decremented cfa_store.offset by the size of the pushed
value, and we're computing the offset of VALUE from the CFA.  For
pre-decrement, the value is stored at the CFA offset (the else);
for post-decrement, the value is stored just above the CFA offset.

I admit the logic is confusing here, because we're storing some
quantities as positive offsets, and some quantities as negative
offsets, and we're also using the same variable for two different
things over two sections of code.  Perhaps it would have been less
obtuse if I had written

	offset = -(cfa_store.offset - offset);

> However I have one simple question with regarding the output: The CFI
> instructions for registers have changed only after the prologue. (For
> convenience I have attached disassembly too). As far as I understand,
> DWARF2 spec emits CFI instructions immediately. (Appendix 5 of DWARF2
> specification)

GCC is attempting to minimize the number of advance opcodes by grouping
the DW_CFA_offset opcodes.  We can delay emission of such until the 
registers in question are actually clobbered.  In this case this delay
tactic failed because of the push -- we cannot delay changes to the CFA.

> The other scenario is - how about functions with signals/interrupts?
> The compiler will give an ICE compiling a function as below:
> 
> void my_interrupt_handler() __attribute__ (("interrupt"));

It's a bug in the avr backend; the enable_interrupt insn should not be
marked as frame-related.  We should fix this separately.


r~