From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23876 invoked by alias); 24 Oct 2014 19:49:23 -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 23864 invoked by uid 89); 24 Oct 2014 19:49:23 -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-la0-f42.google.com Received: from mail-la0-f42.google.com (HELO mail-la0-f42.google.com) (209.85.215.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 24 Oct 2014 19:49:22 +0000 Received: by mail-la0-f42.google.com with SMTP id gf13so3580930lab.29 for ; Fri, 24 Oct 2014 12:49:18 -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=cpUZ1UMHAOJKQH5VZNyiSXxNiKK0LrewWjo28jY7u+0=; b=Y0GxpYZNWeanEsQ/i7Od2y2MppMzAZF3r8V8DuR0RJhgrJTA4EsvTRcvXgP4d/LjcM KeF5I1ZxEMZftC+1Y2qu/MKPaRgsfZVRnAGAG5uTh6j02gltreQr5FAEnwDKC2KYy1GY 5KaWw3w06WJXLyTazGMW0jXZCNJft2lRQotzwnv0AgIyJKCCuEs4xvzI19EVrcbM444i g+ogdSvZrFlkXOHUyfdZxhwXaBfbkaW/waCdDd5Mx/4U4rOX9nVYA5DMBQs92pQA2VIM BLh4L9iQJceUlGAFSXfzukibZQFFTDVN8MrP6ySTIv1jx4LTJTlk3PorGHsdnxPHRPzE /lQQ== X-Gm-Message-State: ALoCoQlS7Xh4LszdJCIs1gvDtjyw+vNbENgp0so02hQ4nBiQ6uFPzk7SDX1RR1UzTaHFEp5qWwu3 MIME-Version: 1.0 X-Received: by 10.112.140.135 with SMTP id rg7mr6761692lbb.24.1414180158105; Fri, 24 Oct 2014 12:49:18 -0700 (PDT) Received: by 10.112.59.129 with HTTP; Fri, 24 Oct 2014 12:49:17 -0700 (PDT) In-Reply-To: <544A68B1.9000909@redhat.com> References: <1413986485-4673-1-git-send-email-martin.galvan@tallertechnologies.com> <544822D6.8020606@redhat.com> <544828BB.9040900@redhat.com> <544A68B1.9000909@redhat.com> Date: Fri, 24 Oct 2014 19:49:00 -0000 Message-ID: Subject: Re: [PATCH] Python API: Add gdb.is_in_prologue and gdb.is_in_epilogue. From: Martin Galvan To: Pedro Alves Cc: gdb-patches@sourceware.org, Doug Evans , Eli Zaretskii , Ulrich Weigand , Daniel Gutson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2014-10/txt/msg00672.txt.bz2 On Fri, Oct 24, 2014 at 11:56 AM, Pedro Alves wrote: > On 10/23/2014 06:36 PM, Martin Galvan wrote: >>> > Some targets have code at address 0. Seems like we may be exposing a >>> > bad interface for these targets here? >> I used 0 because in_prologue expects it to be non-zero. If it's 0 and >> we have no debugging info, it'll always return true: >> >> /* We don't even have minsym information, so fall back to using >> func_start, if given. */ >> if (! func_start) >> return 1; /* We *might* be in a prologue. */ > > Design mistakes in the internal APIs shouldn't be exposed to a public > API. I'd even suggest that whatever Python API we end up with, it'd > be good to make the internal API match it. > >> >> Again, I did it because of the way in_prologue works, but as Eli said >> this would probably be better handled with a Python exception or a >> message of some kind. > > Not sure an exception makes sense given the function's > interface. Say in the future another optional parameter is added. > What would you do then? What of old code that passed in func_start > but not that new argument? Those might not expect an exception. > So for the case of the new argument not being specified, we'd > have to return 1, which is right -- the PC _might_ be pointing > at a prologue. I probably didn't make myself clear-- I wasn't talking about using in_prologue directly anymore, but to follow its approach in the API function. Of course it wouldn't make sense to put Python exception raising directly inside in_prologue. > But, how exactly were you planning using the gdb.is_in_prologue > function? GDB itself doesn't use this to determine whether locals > are valid, only gdbarch_in_function_epilogue_p/gdb.is_in_epilogue. Well, I followed the code while testing a rather simple function and noticed that handle_step_into_function is very similar (in terms of the approach) to in_prologue plus some address corrections and setting a breakpoint to proceed to. The API function needs only the address calculation part. What if: 1) I split handle_step_into_function in the address calc part and the brakpoint insertion part, moving the address calc to a new function (publicly available from infrun.h= ). 2) I expose such function to the Python API. Would that be accepted? Would you want to see a patch? Please keep in mind that what I actually need is not really messing with the prologue, but to know where the local variables are accessible. If I could simply use DWARF info to accomplish that then I wouldn't even touch the prologue at all. Thanks! --=20 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