From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29947 invoked by alias); 6 Dec 2003 00:42:58 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 29940 invoked from network); 6 Dec 2003 00:42:58 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 6 Dec 2003 00:42:58 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id hB60gv224022 for ; Fri, 5 Dec 2003 19:42:57 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hB60gpb21551; Fri, 5 Dec 2003 19:42:51 -0500 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id hB60go629748; Fri, 5 Dec 2003 16:42:50 -0800 Message-ID: <3FD1260A.8080903@redhat.com> Date: Sat, 06 Dec 2003 00:42:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joel Brobecker CC: gdb-patches@sources.redhat.com Subject: Re: [RFC] Unexpected automatic language switch - get_frame_language() References: <20031205224807.GE716@gnat.com> <3FD11B60.2040008@redhat.com> <20031206001815.GF716@gnat.com> In-Reply-To: <20031206001815.GF716@gnat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00234.txt.bz2 Joel Brobecker wrote: >>Sounds kinda like a debugging-optimized-code problem. Your function >>is tail-return optimized -- doesn't really return. That's outside >>the expected API. > > > Kind of, yes, but the code in question was compiled at -O0! Never the less... > It's a > noreturn function because the compiler could statically determine that > the exception would be unhandled. Maybe the compiler shouldn't do that at -O0? >>I think you have to do "special" things for non-returning functions. >>I've seen the same sort of thing for eg. _exit. > > > Do you remember how these similar problems were approached and solved? Ummm... ok, this is embarassing. Well, note that this was written (by me) for a specific target architecture, and never expected to be portable. This little piece of work was called from iq2000_frame_saved_pc: /* Function: horrible_noreturn_hack If the return address points to the first instruction of a function, decrement the return address by one instruction. */ static void iq2000_horrible_noreturn_hack (struct frame_info *fi) { /* Some functions (notably those that are not expected to return) seem to end with a jump_and_link instruction (plus a no-op). When this happens, the return address seems to be the first instruction of the next function. This messes up the backtrace. I can think of no legitimate way that the return address could actually be the first address of a function, [NOTE: except for the entry point address for a call dummy], so if we detect this, we'll decrement it by one instruction (so that it hopefully points into the previous function). */ if (fi && fi->extra_info && fi->extra_info->frame_cached_pc) if (get_pc_function_start (fi->extra_info->frame_cached_pc) == fi->extra_info->frame_cached_pc) if (fi->extra_info->frame_cached_pc != entry_point_address ()) fi->extra_info->frame_cached_pc -= SIZEOF_IQ2000_INSN; }