Re: [RFC] Arm frame unwinding directives.

[Paul Brook <paul at codesourcery dot com>]

On Wednesday 23 June 2004 16:10, Richard Earnshaw wrote:
> On Tue, 2004-06-22 at 17:03, Paul Brook wrote:
> > I'm currently working on implementing EABI compliant exception
> > handling/frame unwinding for arm targets. This involves generating frame
> > unwind tables.
> >
> > My current thinking is that the best way to generate these is via
> > assembly directives embedded in the function code. This has some
> > advantages over generating raw data tables in the compiler:
> > - It allows easy annotation of hand-written assembly code.
> > - It simplifies the compiler.
> > - Maybe allows the assembler to pick an appropriate personality
> > routine/format based on the function size.
> > A similar technique is used by ia64 targets.
>
> A couple of questions:
>
> 1) Can you describe a thumb prologue sequence with the examples (need to
> consider both saving/restoring HI regs and use of a 'frame' pointer).

Yes, see below.

> 2) How would you describe a function where the entry point wasn't at the
> beginning of a region, or where the exit sequence wasn't at the end
> (consider the hot-and-cold regions support now in gcc).

It doesn't matter where the entry/exit sequences are because the abi assumes 
that can't throw exceptions. Under my proposal you could emit all the unwind 
directives at the start of the function and get the same effect. interleaving 
them with instructions is only for convenience. The only restriction is that 
the directives are 'executed' in the order they appear in the source.

For multiple entry points we must assume they all create equivalent stack 
frames, and only emit one set of unwind directives. Multiple exit points 
aren't annotated, so "just work".

I need to think a bit more about hot/cold sections. We will need to output a 
separate unwind table entry for each section. They would have the same unwind 
info, but different personality routine data. It'd be nice if this could be 
done without duplicating all the directives.

> Being able to support 1) is essential for any viable solution -- I'm
> less concerned about 2) but it would certainly be useful in some
> circumstances.

An example compiled with -O2 -mthumb -fno-omit-frame-pointer:

void bar (void);
int
foo (int a)
{
  asm volatile ("" ::: "r8");
  bar ();
  return a;
}

Gives:
        .text
        .align  2
        .global _Z3fooi
        .code 16
        .thumb_func
        .type   _Z3fooi, %function
_Z3fooi:
	.unwind_fnbegin
	.unwind_save {r4, r7, lr}
        push    {r4, r7, lr}
        mov     r7, r8
	.unwind_save {r8}
        push    {r7}
	.unwind_setfp sp
        mov     r7, sp
        mov     r4, r0
        bl      _Z3barv
        mov     sp, r7
        mov     r0, r4
        @ sp needed for prologue
        pop     {r3}
        mov     r8, r3
        pop     {r4, r7, pc}
	.unwind_fnend
        .size   _Z3fooi, .-_Z3fooi
And generates the following unwind opcodes:
sp = r7
POP {r8}
POP {r4, r7, lr}

Paul