From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18387 invoked by alias); 27 Dec 2011 04:56:45 -0000 Received: (qmail 18376 invoked by uid 22791); 27 Dec 2011 04:56:44 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Dec 2011 04:56:18 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 4A4252BAF62; Mon, 26 Dec 2011 23:56:17 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zjYvHGh9-tPg; Mon, 26 Dec 2011 23:56:17 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C3BDE2BAF33; Mon, 26 Dec 2011 23:56:16 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id EF1E7145615; Mon, 26 Dec 2011 20:56:06 -0800 (PST) Date: Tue, 27 Dec 2011 06:23:00 -0000 From: Joel Brobecker To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [patch] Fix gdb.cp/gdb2495.exp regression with gcc-4.7 Message-ID: <20111227045606.GE23376@adacore.com> References: <20111222202047.GA16110@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111222202047.GA16110@host2.jankratochvil.net> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-12/txt/msg00831.txt.bz2 > gcc (GCC) 4.7.0 20111222 (experimental) > on Fedora Rawhide (pre-17) x86_64 as the function before _start is PLT and > PLTs have no proper .eh_frame entries. Still such .eh_frame PLT entry sure > does not apply for the frame. Therefore it > unwinds into garbage and then crashes on it (PC is 0x1 abo-ve). At first sight, it makes sense to choose the next instruction as the return address, the same way call instructions do (which is why unwinders have to subtract 1 from the return address to get the actual calling instruction). The situation is a little different in this case, as the function at the entry point is not actually really the one making the call. How can we convince ourselves that we are not exchanging one wrong by another wrong which just happens to work better for the example at hand? (real question, not rethorical) > +# It should be at least as maximum of all the supported architectures. > +V:ULONGEST:max_insn_length:::31:31 Let's take this opportunity to document the unit used for this size (bytes, right?). > + /* If the inferior call throws an uncaught C++ exception the inferior > + unwinder will try to unwind all the frames incl. the dummy frame. > + Using the entry_point_address directly will try to find FDE at the > + function right before the entry_point_address address as the > + unwinder subtracts 1 to get at the call instruction. FDE of the > + preceding function, if found, would be invalid for the dummy frame > + and it would crash the inferior's unwinder. Therefore attempt to > + skip the very first instruction of entry_point_address. */ Minor edit (punctuation and maybe being more explicit on who does what, and also reformatting to keep it close to 70 chars max - as decided during one of our discussions): /* If the inferior call throws an uncaught C++ exception, the inferior unwinder tries to unwind all frames, including our dummy frame. The unwinder determines the address of the calling instruction by subtracting 1 to the return address. So, using the entry point's address as the return address would lead the unwinder to use the unwinding information of the code immediately preceding the entry point. This information, if found, is invalid for the dummy frame, and can potentially crash the inferior's unwinder. Therefore, we try using the second instruction, right after the one at the entry point's address. */ > + { > + /* No problem probably occurs without this adjustment. INSN_LEN > + may be for example larger than the entry_point_address code. */ > + } /* If we cannot read INSN_LEN bytes (INSN_LEN might be larger than the entry_point_address code, for instance), it is probably fine to leave the return address at the entry point. */ Why would we think that, though? This might be related to may question at the start of this email... -- Joel