This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ppc64 unwinding problem
- From: Richard Henderson <rth at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: David Edelsohn <dje at watson dot ibm dot com>, gcc at gcc dot gnu dot org
- Date: Fri, 11 Jul 2003 14:58:15 -0700
- Subject: Re: ppc64 unwinding problem
- References: <20030711205737.GL20507@sunsite.ms.mff.cuni.cz>
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.
> (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...
The test case looks ok.
r~