This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] Fix ffi powerpc64 unwind info


Hi!

When libgcj.so is linked with an anonymous version script which hides all
the symbols which aren't part of the libgcj.so ABI (e.g. GC_*, ffi_*, fdlibm
symbols, etc.; will post such a patch soon), invokethrow test fails on
ppc64.  The reason for this is no explicit unwind info for the r2 (TOC)
register.  ffi_call_LINUX64 explicitely saves this register, but doesn't
mention that in the unwind info.  Unwinding on ppc64 implicitly 
adds a rule to restore r2 if the instruction at RA is ld %r2, 40(%r1)
(that's what the linker replaces nops after bl instructions with it
it calls something which (maybe) needs a different TOC pointer.
When ffi_call symbol is exported out of libgcj.so, unwinding sort of works
fine, eventhough %r2 in ffi_call_LINUX64 and ffi_call is wrong, there are no
catch regions in those and as all calls to ffi_call in that case are
followed by ld %r2, 40(%r1), TOC register is correctly unwinded at least
in ffi_call caller and above.  But when ffi_call is hidden within
libgcj.so (and ffi_call_LINUX64 is hidden there too, which is the case for
several years no), r2 will be wrong even in ffi_call caller when unwinding
and as _Jv_Throw has try { ffi_call (...); } catch (...) { ... } construct
around it, invokethrow test crashes.

Attached are two possible fixes, one doesn't chance the code at all,
just adds CFA expression where r2 is saved, the other moves ld %r2, 40(%r1)
instruction around to force the implicit unwinder behavior.

Ok for head?  Which one?

	Jakub

Attachment: P
Description: Text document

Attachment: Q
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]