[avr] gas support for cfi info
Richard Henderson
rth@redhat.com
Thu Feb 17 19:53:00 GMT 2011
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~
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: z-gcc-2
URL: <http://sourceware.org/pipermail/gdb/attachments/20110217/89862d20/attachment.ksh>
More information about the Gdb
mailing list