From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-120907-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 4574 invoked by alias); 19 Mar 2015 00:36:20 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Received: (qmail 4559 invoked by uid 89); 19 Mar 2015 00:36:19 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-HELO: mail-ig0-f176.google.com
Received: from mail-ig0-f176.google.com (HELO mail-ig0-f176.google.com) (209.85.213.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 19 Mar 2015 00:36:18 +0000
Received: by igcau2 with SMTP id au2so79080423igc.0        for <gdb-patches@sourceware.org>; Wed, 18 Mar 2015 17:36:16 -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;        bh=8YhQU7zpyfugs1WzaMkVeCq/vkHbOpYDfcYHjyr+p/o=;        b=cKUbP6OAl6hAFdyiag3N/TuiRmXn10Dx7fH8c8AxzfEvr3sy2GB2EtK4ttKqEvC03M         0sAOHFbXKA5j0nL4ftJH+CwZv6Uuh3OIERsrAT10jMoWpTHvTDCUKWx4H3Kzeqtctn+u         8yfyQOziP2Ik/wdkPrHInJ96RAEYxVu5TAeF1EoYZs7BzCElJCd5uninTWlWDZtNfksM         wfHXQmE2sbdbJWQ2NHx3ixF4AXQlH5yRqaOR3mmCLmLmGjXhKmxWfg5opSNWKGsMtiQ8         QQ9dLghmfw7S1Xo/wLw3Ke5H7HkZolVAvYqqjLNeo1iFyjtDR21Ft2RKkWnSIj3PlenD         KFpA==
X-Gm-Message-State: ALoCoQk0+tqdzShBHZRgCcQfvds6olv/0gLeBbY5liBNKIR0OS8iJsjd+GUgXhEhAdO9ol6QF8ra
MIME-Version: 1.0
X-Received: by 10.50.107.7 with SMTP id gy7mr11703336igb.49.1426725376593; Wed, 18 Mar 2015 17:36:16 -0700 (PDT)
Received: by 10.64.98.103 with HTTP; Wed, 18 Mar 2015 17:36:16 -0700 (PDT)
In-Reply-To: <CADPb22TW2YC3CLBO9bJGhV7KPM4=mvGoP0AgEd9r8Vd=J0XVxQ@mail.gmail.com>
References: <CAHQ51u7NUoQ8w9c5mc-Eiz05b1Nub6zqj_Ne7vfgWb5EP9_X8w@mail.gmail.com>	<21714.40641.510825.30998@ruffy2.mtv.corp.google.com>	<CAHQ51u5_ViLaEmv9e43R-wzuWw8dwNkb-2XgCRy5ELQq5FUAWg@mail.gmail.com>	<54E71694.1080304@redhat.com>	<CAHQ51u75+9HYAVJXYNQa0gTnQtYKEgmSkyAhAPYp-y4HGtXssg@mail.gmail.com>	<CAHQ51u6UZ7A47rpGgX0QGeYSTCz1eo_3jWHc=q2ZX3YhqcJ6iQ@mail.gmail.com>	<87ioei31uj.fsf@igalia.com>	<CAHQ51u4f+Vx7qXPm-KAAENOceaVogMbDMw6==N_nY+GrLr4Pgg@mail.gmail.com>	<87d24p19tt.fsf@igalia.com>	<54FD7DAA.7010603@redhat.com>	<CAHQ51u7sUkGhkmvTaaO_Jo6Jn+kojfiMWHmc2=7OWHThAq6EKw@mail.gmail.com>	<87twxrncld.fsf@igalia.com>	<CAHQ51u60nHp1a2DXZ4srvRefyTtge1BUw7-=JuYqChHN_wUGyQ@mail.gmail.com>	<87ioe1dvu2.fsf@igalia.com>	<CAHQ51u7KzQLSLC=QeLA=zd+TUkbbNzzndfeVLFWpjiR-pL8ang@mail.gmail.com>	<87sid4atms.fsf@igalia.com>	<CAHQ51u6=9BKf6YSTavbY7u_Mi6miKJ_Yo1QcaG=KsYtYzoWY_Q@mail.gmail.com>	<CADPb22TW2YC3CLBO9bJGhV7KPM4=mvGoP0AgEd9r8Vd=J0XVxQ@mail.gmail.com>
Date: Thu, 19 Mar 2015 00:36:00 -0000
Message-ID: <CAHQ51u43Xr3Lc3LT8sQogSuNLaz8cXku3JH0A5LdT=ofvC_PDw@mail.gmail.com>
Subject: Re: [RFC] [PATCH] Provide the ability to write the frame unwinder in Python
From: Alexander Smundak <asmundak@google.com>
To: Doug Evans <dje@google.com>
Cc: Andy Wingo <wingo@igalia.com>, gdb-patches <gdb-patches@sourceware.org>
Content-Type: text/plain; charset=UTF-8
X-SW-Source: 2015-03/txt/msg00571.txt.bz2

> Regarding the result of an unwinder/sniffer,
> If I approach this from the point of view of what's
> easy to explain, it feels like the result of an Unwinder
> is a Frame.
It is logical, but that's not what GDB core expects from the unwinder.
I hesitate to have Python frame unwinder API differ too much from
 the underlying GDB core API.

> Would it make sense to speak of an Unwinder taking
> an EphemeralFrame as input and returning a Frame as output?
Existing gdb.Frame interface wraps GDB core's `frame_info',
providing read-only capability and no instance construction.
An object returned by a Python unwinder is quite different.