From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31062 invoked by alias); 22 Oct 2014 19:23:50 -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 31049 invoked by uid 89); 22 Oct 2014 19:23:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f202.google.com Received: from mail-pd0-f202.google.com (HELO mail-pd0-f202.google.com) (209.85.192.202) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 22 Oct 2014 19:23:47 +0000 Received: by mail-pd0-f202.google.com with SMTP id fp1so716071pdb.5 for ; Wed, 22 Oct 2014 12:23:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:content-type :content-transfer-encoding:message-id:date:to:cc:subject:in-reply-to :references; bh=iSzJM3Ko+yNbAPy/kcELkMfssOiM0/Aia5oA/2Wmtjg=; b=kLCPR5Ei1YRJmtsIcaAxmNVfHSskP5+n7MfJ8niTxkm+vxAL/9FPaC8ai3MAo+FYgq +nrxEo+ecRl49BGot+wTZYpSDffDSwGQrBWGVSuajmCP2N73/dLv6YAcMyJ3Hhy4f/bM TVnyN6Kv/XEyf8cVkvXemvEEjRtCOtYLyv5HW1ePM6eVBi6DFVW8x9PrdcmVCdYNfsCS KY86QJaCJH0KoMrGUIUnTFcbtP+DIDD4eWupD70X9Hnaf8P0TkOFPtYiyiClPwb4WOOu QGhCj4O3Fegtd85lnjGKNBtqIaMhj3MuzZ7CyuHiOTSpwG3KI5ifK4wNmc5mXhyvSky8 xlIQ== X-Gm-Message-State: ALoCoQln/hXSu5Tk9QACMqhc7kjfLGl5pXJ/5eqqhvBkgwf/Ju1Fh2aoq2pTiHoGc1CBHKNlnMgZK+oqOFM2VDnemuxyxGolOlAvTEDNAM5nKcpqCG3xZZ9xyE8LICT0avKS1YZtmLBPBp6cuKmgXjsC9AJQPSlieY2wXvIK4mc8aLnXHLN+Q3c= X-Received: by 10.66.90.201 with SMTP id by9mr163974pab.24.1414005825738; Wed, 22 Oct 2014 12:23:45 -0700 (PDT) Received: from corpmail-nozzle1-1.hot.corp.google.com ([100.108.1.104]) by gmr-mx.google.com with ESMTPS id t28si724108yhb.4.2014.10.22.12.23.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Oct 2014 12:23:45 -0700 (PDT) Received: from ruffy.mtv.corp.google.com ([172.17.128.44]) by corpmail-nozzle1-1.hot.corp.google.com with ESMTP id ugrlBVpP.1; Wed, 22 Oct 2014 12:23:45 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21576.1088.684481.249056@ruffy.mtv.corp.google.com> Date: Wed, 22 Oct 2014 19:23:00 -0000 To: Martin Galvan Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Python API: Add gdb.is_in_prologue and gdb.is_in_epilogue. In-Reply-To: <1413986485-4673-1-git-send-email-martin.galvan@tallertechnologies.com> References: <1413986485-4673-1-git-send-email-martin.galvan@tallertechnologies.com> X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00589.txt.bz2 Martin Galvan writes: > Added two new functions to the Python API: gdb.is_in_prologue and gdb.is_in_epilogue. > These expose the in_prologue and gdbarch_in_function_epilogue_p functions > respectively, which are useful for checking if the values of local variables are > valid when single-stepping through machine instructions. > > Also added tests for gdb.is_in_prologue only. The reason of this is that > the tests work by checking the first instruction of a given function, as that's > conventionally part of the prologue. Testing gdb.is_in_epilogue seems to be > architecture-dependant (for instance, the last instruction of a function is > reported as part of an epilogue by gdbarch_in_function_epilogue_p for ARM, > but not always for x86_64), so I didn't include a test for it. Hi. We should have a test for is_in_epilogue anyway. The canonical choice is to just make it amd64-linux specific. API functions like these are problematic. Users don't expect API functions to be heuristic-based, and that is all these can ever be in the general case. The patch does try to provide the user some guarantees ("however if the result is @code{False} you can be sure @value{GDBN} is right."), but it's not clear to me this will be true in the general case. I may have missed something so I'm certainly willing to be persuaded otherwise. I might be ok with this patch if the functions were named something like "maybe_is_in_prologue" and "maybe_is_in_epilogue". That way they scream to the user (and future code readers) "Heads Up!"