Re: [avr] gas support for cfi info

[Richard Henderson <rth at redhat dot com>]

On 02/17/2011 08:04 AM, Richard Henderson wrote:
>> 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.

Looking at this closer, it seem that the FRAME_RELATED markers in avr.c
were sprinkled at random without really knowing what is going on.  There
were 2 places where UNSPEC_VOLATILE insns were marked frame related,
somehow expecting the unwinder to do something magical.

The following cleans all that up.  There are a couple of odd points:

  (1) SREG and RAMPZ cannot be annotated as saved in the frame of an
      interrupt function without allocating hard register numbers for
      these registers.  Not to be confused with "real" registers, 
      these need a number in the same way that SP_L and SP_H have
      register numbers.

      I've simply ignored unwind info for these for now.

  (2) At present it's possible to use epilogue_restores without
      having used prologue_saves.  I.e. use epilogue_restores with
      an inline prologue.  The problem being that the inline prologue
      uses an HImode push of REG_Y (i.e. r29 first), whereas the code
      in prologue_saves pushes r28 first and epilogue_restores is
      written to expect that.

      I've changed the inline prologue and epilogue to emit explicit
      byte push/pop for r28/r29 in numerical order to match the 
      external routines.

      This has a side effect that r29 actually receives unwind info.
      The generic unwinder doesn't expect to see multi-register
      saves, and only emits one unwind opcode for each save.


r~

Attachment: z-gcc-2
Description: Text document