.cfi_signal_frame semantics; .eh_frame versus .debug_frame

Hi guys,

I have two questions about how gcc/gdb handle DWARF.

I have been looking at the x86 vdso code, and I found that the signal
return handlers for the i386 (32 bit) code use open-coded DWARF
annotations which look, at the very best, iffy.

I would like to replace them with .cfi_* annotations, and I found
.cfi_signal_frame.  However, this flag just sets an "augmentation" bit,
and I cannot really find the semantics of that annotation.

One weird thing about these stubs is that the "sigreturn" stub, but not
"rt_sigreturn", needs to pop a word off the stack before calling the
underlying system call.

Demacroized, this is my best attempt at mimicking what the current code
does, but I have no idea if this is either necessary or correct.  Most
other architectures seem to only have the .cfi_signal_frame annotation
and nothing else...

        .cfi_sections .eh_frame

        .macro SIGNAL_FRAME offset
        .cfi_signal_frame
        .cfi_def_cfa    esp,  \offset
        .cfi_offset     ss,  12
        .cfi_offset     eflags, 20
        .cfi_offset     cs,  24
        .cfi_offset     eip, 28
        .cfi_offset     eax, 40
        .cfi_offset     ecx, 44
        .cfi_offset     edx, 48
        .cfi_offset     ebx, 52
        .cfi_offset     esp, 56
        .cfi_offset     ebp, 60
        .cfi_offset     esi, 64
        .cfi_offset     edi, 68
        .cfi_offset     esi, 64
        .cfi_offset     edi, 68
        .cfi_offset     ds,  72
        .cfi_offset     es,  76
        .cfi_offset     fs,  80
        .cfi_offset     gs,  84
        .endm


        .text
        .align 8
        .globl  sigreturn
        .type   sigreturn, @function
sigreturn:
        .cfi_startproc simple
        SIGNAL_FRAME 4
        popl    %eax
        .cfi_adjust_cfa_offset -4

        movl $119, %eax
        int $0x80
        .cfi_endproc
        .size   sigreturn,.-sigreturn

        .align 8
        .globl  rt_sigreturn
        .type   rt_sigreturn, @function
rt_sigreturn:
        .cfi_startproc simple
        SIGNAL_FRAME 0

        movl $173, %eax
        int $0x80
        .cfi_endproc
        .size   rt_sigreturn,.-rt_sigreturn
        .previous


---- ----

... but I'm not sure that enumerating the frame is supposed to be either
necessary or correct, and how the offset needs to be handled.

Another issue that I have been trying to deal with is that currently the
assembly code uses:

	.cfi_sections .eh_frame, .debug_frame

... but it looks like gcc only generates one or the other, at least for
relatively simple code.  dwarfdump barfs on a .debug_frame that contains
.cfi_signal_frame whereas it has no problem with .eh_frame.

Is there a reason to produce .debug_frame?

I have also noticed that there is a "leak" of the kernel compile flags
into the vdso compilation which means that sometimes the .eh_frame in
the vdso *only* contains the output of assembly code; this seems to be a
matter of adding an unconditional -fasynchronous-unwind-tables to the
32-bit vdso build (it is already there for the 64-bit vdso.)

So, any assistance in straightening out my understanding here would be
appreciated.

	-hpa