ppc64 unwinding problem

[Jakub Jelinek]

On Fri, Jul 11, 2003 at 02:58:15PM -0700, Richard Henderson wrote:
> On Fri, Jul 11, 2003 at 10:57:37PM +0200, Jakub Jelinek wrote:
> > This is very bad, not only because some libgcj stuff does not work
> > (there are other bugs on ppc64 in gcj), but because NPTL relies on this.
> 
> Hum.  Well, IMO the best solution to the unwinding problem is
> to have signal trampolines that have proper unwind info.  Does
> ppc64-linux allow for an sa_restorer that glibc could set up?
> If so, then at least NPTL is set.

That does not change anything on the above problem though.
If rs6000_emit_eh_toc_restore is kept (and unchanged), it would still
segfault no matter whether it has unwind info or whether
MD_FALLBACK_FRAME_STATE_FOR does the job.

> > (I don't think if (*($r1 + 16) == 0xE8410028) DW_CFA_offset (2, -40);
> > else do nothing is expressible in Dwarf2)
> 
> Well, if we can assume that R2 has an entry at top-level (i.e.
> in _Unwind_RaiseException etc), then I would think that
> 
> 	// CFA == $r1, which is at TOS on entry
> 
> 	DW_OP_dup
> 	DW_OP_plus_uconst 16
> 	DW_OP_deref_size 4
> 	DW_OP_const4u 0xE8410028
> 	DW_OP_eq
> 	DW_OP_bra 1f
> 	DW_OP_reg2
> 	DW_OP_skip 2f
> 1:	DW_OP_const1u 40
> 	DW_OP_minus
> 2:	DW_OP_nop
> 
> would do that job.  No idea where you'd put this...

Seems like:
        .byte   0x10     # DW_CFA_expression
        .uleb128 0x2
        .uleb128 .LCFAEND-.LCFASTART
.LCFASTART:
        .byte   0x12     # DW_OP_dup
        .byte   0x23     # DW_OP_plus_uconst
        .uleb128 0x10
        .byte   0x94     # DW_OP_deref_size
        .byte   0x8
        .byte   0x94     # DW_OP_deref_size
        .byte   0x4
        .byte   0xc      # DW_OP_const4u
        .4byte  0xe8410028
        .byte   0x29     # DW_OP_eq
        .byte   0x28     # DW_OP_bra
        .2byte  .LCFA2-.LCFA1
.LCFA1:
        .byte   0x52     # DW_OP_reg2
        .byte   0x2f     # DW_OP_skip
        .2byte  .LCFA3-.LCFA2
.LCFA2:
        .byte   0x23     # DW_OP_plus_uconst
        .byte   0x28
.LCFA3:
.LCFAEND:

at the end of CIE cfa program might do the job (I haven't touched gcc bits
yet, so I just stepped through libgcc_eh.a to see whether it does
what it is supposed to do).

Now, there is one problem: binary compatibility.
So far libgcc_eh.a was doing this in __builtin_eh_return, ie. without
need for explicit CFA code in .eh_frame/.debug_frame.
If __builtin_eh_return gets rid of the hack, then we either suddenly
stop working with all binaries/shared libraries which don't have
the above magic in CIE programs (but it would be certainly cleanest),
or we could e.g. by some MD_CFA_PROGRAM macro just run the above code
through execute_cfa_program at the end of each CIE program implicitely.

In both cases it would need some changes into the backend, so that
r2 is saved initially and restored in __builtin_eh_return.

	Jakub