From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30363 invoked by alias); 23 Oct 2014 17:57:43 -0000 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 Received: (qmail 30345 invoked by uid 89); 23 Oct 2014 17:57:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: e06smtp13.uk.ibm.com Received: from e06smtp13.uk.ibm.com (HELO e06smtp13.uk.ibm.com) (195.75.94.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 23 Oct 2014 17:57:41 +0000 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 23 Oct 2014 18:57:38 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 23 Oct 2014 18:57:36 +0100 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id F08EF2190046 for ; Thu, 23 Oct 2014 18:57:11 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id s9NHvZTe5898538 for ; Thu, 23 Oct 2014 17:57:35 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s9NHvYDs026811 for ; Thu, 23 Oct 2014 11:57:35 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with SMTP id s9NHvX3r026780; Thu, 23 Oct 2014 11:57:33 -0600 Message-Id: <201410231757.s9NHvX3r026780@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 23 Oct 2014 19:57:33 +0200 Subject: Re: [PATCH] Python API: Add gdb.is_in_prologue and gdb.is_in_epilogue. To: martin.galvan@tallertechnologies.com (Martin Galvan) Date: Thu, 23 Oct 2014 17:57:00 -0000 From: "Ulrich Weigand" Cc: palves@redhat.com (Pedro Alves), gdb-patches@sourceware.org, dje@google.com, eliz@gnu.org (Eli Zaretskii) In-Reply-To: from "Martin Galvan" at Oct 23, 2014 02:36:24 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14102317-0013-0000-0000-00000196127A X-SW-Source: 2014-10/txt/msg00609.txt.bz2 Martin Galvan wrote: > Well, the comment at the top of in_prologue says "Returns 1 if PC > *might* be in prologue, 0 if definately (sic) *not* in prologue". > However, looking at the function itself it relies on the compiler > having marked the prologue as its own "line", and if it can't use that > info it falls back to using the architecture-dependant > gdbarch_skip_prologue. So far every time I've tested it it's worked > fine, and if it didn't it would've probably already been reported as a > bug of in_prologue or gdbarch_skip_prologue. I guess if you want to be > *really* careful I could change that line in the documentation for > something like "if the result is False, you can be almost sure GDB is > right", or "GDB is most likely right". The fundamental problem is that the notion of "prologue" and "epilogue" simply no longer exists in optimized code generated by modern compilers; and even more compiler features get implemented that make those notions even less useful (e.g. shrink-wrapping). As a result, we have been trying to the rid of using those notions as much as possible; for example, when debugging optimized code with modern DWARF information present, GDB will today no longer even use prologue skipping at all. Instead, the debug information is good enough that the correct location of local variables can be recovered at every instruction in the function, making the distinction no longer needed. The in_prologue routine is likewise only still uses under certain rather rare circumstances; in fact it might even today be possible to simply remove it. Once more platforms provide correct DWARF covering epilogues as well, the gdbarch_in_function_epilogue_p calls in breakpoint.c may likewise become unnecessary. So if we hope at some point to get rid of those routines, then it seems counterproductive to now export them as part of a fixed external API ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com