This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: eh info and unaligned dynamic relocations
- To: Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>
- Subject: Re: eh info and unaligned dynamic relocations
- From: Richard Henderson <rth at redhat dot com>
- Date: Thu, 7 Jun 2001 17:11:28 -0700
- Cc: gcc-patches at gcc dot gnu dot org, mark at codesourcery dot com, oldham at codesourcery dot com, "Jeffrey A. Law" <law at redhat dot com>
- References: <20010605142110.A30865@redhat.com> <yddofs1708s.fsf@xayide.TechFak.Uni-Bielefeld.DE>
On Wed, Jun 06, 2001 at 11:43:31PM +0200, Rainer Orth wrote:
> Unaligned access pid=279788 <g++-eh-badalloc1> va=0x14000042c
> pc=0x120001fa8 ra=0x120001f7c inst=0xa77d80c8
This is a linker bug. The exception handler landing pad contains
an ldgp macro, which is supposed to recalculate the GP based on a
register containing the current address:
.align 4
$L80:
ldgp $29,0($26)
The values the linker places in the ldah and lda instructions that
this generates are wrong. We get a GP that is off by four, which
means that all subsequent address loads (1) get unaligned access
faults and (2) read incorrect data.
I have no idea what to do about this. I couldn't find a different
code sequence that didn't have the same problem. I even hacked the
specs file to pass -O0 to ld instead of -O3 and got the same results.
Given that this same sort of situation also occurrs with setjmp based
exceptions, I think you're probably screwed on Tru64 without fixes
from Compaq.
r~