From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12116 invoked by alias); 2 Mar 2006 15:13:40 -0000 Received: (qmail 12103 invoked by uid 22791); 2 Mar 2006 15:13:38 -0000 X-Spam-Check-By: sourceware.org Received: from ip127.bb146.pacific.net.hk (HELO mailhub.stlglobal.com) (202.64.146.127) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 02 Mar 2006 15:13:35 +0000 Received: from localhost ([127.0.0.1]) by mailhub.stlglobal.com with esmtp (Exim 4.50) id 1FEpUW-0005Gh-IQ for gdb@sources.redhat.com; Thu, 02 Mar 2006 23:13:20 +0800 Message-ID: <44070B97.2050707@tausq.org> Date: Thu, 02 Mar 2006 15:13:00 -0000 From: Randolph Chung User-Agent: Debian Thunderbird 1.0.2 (X11/20051002) MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: interesting unwind problem with noreturn functions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00017.txt.bz2 i ran across this when debugging gdb on hppa-linux..... value_from_double calls error() in the case that I was debugging, but if i break in error(), i get a corrupted backtrace. (top-gdb) bt #0 error ( string=0x23d89c "Unexpected type encountered for floating constant.") at ../../gdb-cvs/gdb/utils.c:645 #1 0x000b848c in value_from_double (type=0x31d9d0, num=4.9406564584124654e-324) at ../../gdb-cvs/gdb/value.c:1570 #2 0x000b848c in value_from_double (type=0x31d9d0, num=4.9406564584124654e-324) at ../../gdb-cvs/gdb/value.c:1570 Previous frame identical to this frame (corrupt stack?) looking into this, it looks like gcc is being a bit too clever for gdb.... 000b83dc : b83dc: 6b c2 3f d9 stw rp,-14(sp) b83e0: 6f c3 01 00 stw,ma r3,80(sp) [...] b8484: e8 40 08 bc b,l b98e8 <_initialize_values+0xf3c>,rp b8488: 08 1c 02 5a copy ret0,r26 000b848c : b848c: 6b c2 3f d9 stw rp,-14(sp) b8490: 6f c4 01 00 stw,ma r4,80(sp) b8484 is the call to error (through a long branch stub, so the name looks funny). The return pointer of the call points past value_from_double into the next function (hppa has a delay slot for branches, and rp points to .+8 for a branch insn). Since error() is defined as a noreturn function, I suppose this is a valid thing for gcc to do, even if it looks a bit weird. So when you unwind from error(), the hppa frame unwinder tries to unwind from rp=b848c, which is in a different function from the actual caller, and the unwinder gets all confused.... I suppose this is not a hppa specific thing, other architectures might also encounter the same problem. How is it fixed there? Should the unwinder be storing the PC as RP-offset? (This seems rather ugly, if not wrong.) randolph