From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26730 invoked by alias); 7 Feb 2002 16:30:41 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 26596 invoked from network); 7 Feb 2002 16:30:34 -0000 Received: from unknown (HELO mail.sandvine.com) (209.167.74.226) by sources.redhat.com with SMTP; 7 Feb 2002 16:30:34 -0000 Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Feb 2002 11:30:28 -0500 Message-ID: From: Ed Maste To: "'gcc@gcc.gnu.org'" Subject: Exception unwinding bug Date: Thu, 07 Feb 2002 08:50:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-SW-Source: 2002-02/txt/msg00533.txt.bz2 I've discovered what I believe to be a bug in the exception unwinding code of gcc 3.0.3. I wrote a short test function with just a try & catch in a function, and the unwinder crashes at run time. I've traced the unwinding through to the call to the C++ personality function in eh_personality.cc. At the end of the personality function, _Unwind_SetGR is called to set up a pointer to the exceptionObject for the call to __cxa_begin_catch later on (eh_personality.cc:393): _Unwind_SetGR (context, __builtin_eh_return_data_regno (0), (_Unwind_Ptr) &xh->unwindHeader); _Unwind_SetGR takes an _Unwind_Word as its third argument. I'm using a MIPS processor; sizeof(_Unwind_Ptr) is 32 bits, and sizeof(_Unwind_Word) is 64 bits. _Unwind_Word is an unsigned type (unwind.h:32): typedef unsigned _Unwind_Word __attribute__((__mode__(__word__))); When gcc generates the call to _Unwind_SetGR in the personality function, it takes the &xh->unwindHeader and zero-extends it to 64 bits. Later on, the generated code for my "catch" calls __cxa_begin_catch, and the result of the _Unwind_SetGR is in the a0 register. __cxa_begin_catch tries to read a value from the exceptionObject. The beginning of __cxa_begin_catch looks like this (mips assembly): __cxa_begin_catch: addiu sp,sp,-48 sd s0,32(sp) sd ra,40(sp) jal __cxa_get_globals addiu s0,a0,-48 lw v1,20(s0) So here's the problem: addiu requires its register operand to be a valid 64-bit sign extended representation of a 32-bit value; if it is not, the result is unpredictable[1]. The zero-extended version that the compiler generates violates this rule. This problem won't show up with user pointers that end up < 0x80000000; in kernel mode my pointers are >= 0x80000000. It seems that almost all MIPS processors implement addiu as "do a 32 bit add and then sign extend" so the unpredictable behaviour produces the expected result. The processor I'm working with has different unpredictable behaviour (the result of the addiu still has zeros in bits 63-32), so the "lw" instruction following causes a MIPS processor exception. I can probably work around this by casting the &xh->unwindHeader to a signed word in the personality function. I'm not sure how this should be properly fixed, though, as other architectures might have other issues with such a change. My compiler info: Configured with: configure --target=mips-wrs-vxworks --enable-threads Thread model: vxworks gcc version 3.0.3 [1] http://www.mips.com/publications/documentation/MD00087-2B-MIPS64BIS-AFP-00.9 5.pdf, page 39