From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28823 invoked by alias); 23 Oct 2014 18:14:01 -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 28813 invoked by uid 89); 23 Oct 2014 18:14:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mail-ie0-f170.google.com Received: from mail-ie0-f170.google.com (HELO mail-ie0-f170.google.com) (209.85.223.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 23 Oct 2014 18:14:00 +0000 Received: by mail-ie0-f170.google.com with SMTP id tp5so1490710ieb.15 for ; Thu, 23 Oct 2014 11:13:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UN/6wp+FUIexfS2vgkQGt0G8IyRe1hBranweMWxHAzg=; b=R7rFyJjLuxJqh8kapgbsct9NQ73iJ5tP2okyN1e93xu6NPVN0A0YU3PX2SxPvjpcL7 mK/AUU2DlxAltq5y2bRii5iZS8Q+6/gjRI4hFkOgrZqmGoat7sgLTSyvTkwOx4uHpJxE Hb9RosLnOzHccDkyG3nf+bBfINHFjNPHvLSYjglAm9pCrmUPpiDi4WLUfaSKDFfMU455 WZRXQMGSygs1JczmynpLuEwU8iqucipsQrQeqrDfkOtBXUkcfwEQ4L512HkrtwdhTLAz FOO/6aYW0Jqi+5hnrL1yJgdSUiVC7HPrDpzoZ3EUbd56DDcMpKNhhEIoox4iHnn68q17 ovzQ== X-Gm-Message-State: ALoCoQmmUUksPtyTMipyI76Cmma2g3IfQcOywFYQdBrkSr0FZIr7afE2Pq8WSJC3J0a4JBPosvQW MIME-Version: 1.0 X-Received: by 10.107.150.213 with SMTP id y204mr4154863iod.59.1414088037816; Thu, 23 Oct 2014 11:13:57 -0700 (PDT) Received: by 10.107.156.75 with HTTP; Thu, 23 Oct 2014 11:13:57 -0700 (PDT) In-Reply-To: References: <201410231757.s9NHvX3r026780@d06av02.portsmouth.uk.ibm.com> Date: Thu, 23 Oct 2014 18:14:00 -0000 Message-ID: Subject: Re: [PATCH] Python API: Add gdb.is_in_prologue and gdb.is_in_epilogue. From: Daniel Gutson To: Martin Galvan Cc: Ulrich Weigand , Pedro Alves , gdb-patches , Doug Evans , Eli Zaretskii Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00611.txt.bz2 On Thu, Oct 23, 2014 at 3:09 PM, Martin Galvan wrote: > On Thu, Oct 23, 2014 at 2:57 PM, Ulrich Weigand wro= te: >> 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 ... > > While that may be true, it's also true that at some points we still > see the local variables having wrong values when stepping through > machine code. The aim of this patch is to expose a way of detecting > such situations for scripts that may need it. Until we have a safer > way to do it I think this should be integrated to the code base. Hi all, (Hi Pedro!) we badly need this. If you think the patch is in a shape good enough to be committed, please commit it for Mart=C3=ADn since he doesn't have write access. We can then start a fresh new thread to discuss future directions specially related to optimized code and exactly what/how DWARF tags should be handled. Thanks! Daniel. > > -- > > Mart=C3=ADn Galv=C3=A1n > > Software Engineer > > Taller Technologies Argentina > > San Lorenzo 47, 3rd Floor, Office 5 > > C=C3=B3rdoba, Argentina > > Phone: 54 351 4217888 / +54 351 4218211 --=20 Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 C=C3=B3rdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype: dgutson