From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2109 invoked by alias); 13 Aug 2003 17:31:01 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2087 invoked from network); 13 Aug 2003 17:31:01 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 13 Aug 2003 17:31:01 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 620272B7F for ; Wed, 13 Aug 2003 13:30:56 -0400 (EDT) Message-ID: <3F3A75D0.1020700@redhat.com> Date: Wed, 13 Aug 2003 17:31:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: [Fwd: Unwinding through `no return'?] Content-Type: multipart/mixed; boundary="------------050007040708090805040104" X-SW-Source: 2003-08/txt/msg00138.txt.bz2 This is a multi-part message in MIME format. --------------050007040708090805040104 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 13 FYI, Andrew --------------050007040708090805040104 Content-Type: message/rfc822; name="Unwinding through `no return'?" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Unwinding through `no return'?" Content-length: 3400 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: cagney@localhost.redhat.com Received: from localhost (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E14B62B7F for ; Wed, 13 Aug 2003 11:44:57 -0400 (EDT) X-Sieve: cmu-sieve 2.0 Received: from localhost by localhost with IMAP (fetchmail-6.2.1) for cagney@localhost (single-drop); Wed, 13 Aug 2003 11:44:57 -0400 (EDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h7DFhqO11170 for ; Wed, 13 Aug 2003 08:43:52 -0700 Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with SMTP id h7DFhos22829; Wed, 13 Aug 2003 11:43:51 -0400 Received: from els.sgi.com (els.SGI.COM [192.48.168.14]) by mx1.redhat.com (8.11.6/8.11.6) with SMTP id h7DFhot30826; Wed, 13 Aug 2003 11:43:50 -0400 Received: (from majordom@localhost) by els.sgi.com (8.12.9/8.12.2/els-2.2) id h7DFi6xV4216183; Wed, 13 Aug 2003 08:44:06 -0700 (PDT) Received: from localhost.redhat.com (CPE0030652f1784-CM.cpe.net.cable.rogers.com [24.157.166.107]) by els.sgi.com (8.12.9/8.12.2/els-2.2) with ESMTP id h7D4rAQd4184618 for ; Tue, 12 Aug 2003 21:53:12 -0700 (PDT) Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 21D132B7F for ; Wed, 13 Aug 2003 00:52:36 -0400 (EDT) Message-ID: <3F39C413.8070201@redhat.com> Date: Wed, 13 Aug 2003 00:52:35 -0400 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dwarf 2 List Subject: Unwinding through `no return'? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-dwarf2@els.sgi.com Precedence: bulk Reply-To: Andrew Cagney Content-length: 1356 Hello, A clasic function call sequence will look something look like: push arguments call func pop arguments <- RA When a compiler determines that the function won't return it might convert it into: push arguments call func <- RA I'm trying to understand how CFI should handle this. The problem I've encountered is that the RA provided by func's CFI could end up pointing at totally unrelated instruction For instance the code: bar() { func () // no return } baz () { ... could become: bar: push arguments call func baz: prologue of baz <- RA leading to a bogus unwind (other more edgy cases occure when the call is at the end of a block - this one is easier to explain :-). One `work around' is recognize that func was reached via a call instruction and then use RA-1 to locate the CFI for the function vis: bar: push arguments call func <- (RA-1) baz: prologue of baz That way the address at least falls on an instruction related to the call sequence. Is this accepted best-pratice, or is there a more robust way of handling this? I can see, although off the top of my head I can't think of, an ISA that may need different CFI info for the two cases of: - about to execute ``call func'' - unwinding back through the ``call func'' instruction and the above won't allow that. comments? Andrew --------------050007040708090805040104--