From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-101459-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 13555 invoked by alias); 14 May 2013 13:23:29 -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 13488 invoked by uid 89); 14 May 2013 13:23:28 -0000
X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,FROM_LOCAL_NOVOWEL,HK_RANDOM_ENVFROM,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS autolearn=ham version=3.3.1
Received: from mail-wi0-f171.google.com (HELO mail-wi0-f171.google.com) (209.85.212.171)    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 14 May 2013 13:23:27 +0000
Received: by mail-wi0-f171.google.com with SMTP id hq7so2260033wib.16        for <gdb-patches@sourceware.org>; Tue, 14 May 2013 06:23:25 -0700 (PDT)
X-Received: by 10.180.187.234 with SMTP id fv10mr6521081wic.29.1368537805472;        Tue, 14 May 2013 06:23:25 -0700 (PDT)
Received: from localhost (89-92-181-134.hfc.dyn.abo.bbox.fr. [89.92.181.134])        by mx.google.com with ESMTPSA id fv11sm9626151wic.11.2013.05.14.06.23.24        for <multiple recipients>        (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);        Tue, 14 May 2013 06:23:24 -0700 (PDT)
From: Maxime Coste <frrrwww@gmail.com>
Subject: Re: [PATCH 1/3] Add a select_frame_reason enum parameter to select_frame
To: Pedro Alves <palves@redhat.com>, Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
References: <1367002961-12311-1-git-send-email-frrrwww@gmail.com>	<1367002961-12311-2-git-send-email-frrrwww@gmail.com>	<87r4htxeth.fsf@fleche.redhat.com> <5187E029.8070008@redhat.com>
In-Reply-To: <5187E029.8070008@redhat.com>
MIME-Version: 1.0
Date: Tue, 14 May 2013 13:23:00 -0000
Message-Id: <51923acc.ebbbb40a.3e42.0f2b@mx.google.com>
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2013-05/txt/msg00465.txt.bz2

Hello

On Mon, 06 May 2013 17:54:01 +0100, Pedro Alves <palves@redhat.com> wrote:
> IMO, it'd be better to leave select_frame unaware of why it's being
> called, and just add a wrapper for user visible frame selection.
> It feels like different conceptual levels to me.  IOW, something like:
> 
> void
> select_user_frame (struct frame_info *fi)
> [...]

That seems better to me too, I went the other way because at first I tried
to add checks for frame restoration (there were IMPL_DETAIL_{PUSH,POP}
with a counter checking that only IMPL_DETAIL_* were nested...

I'll prepare a patch using this approach.

> If we limit frame change notifications to user frame changes
> (CLI up/down/frame and MI equivalents), then these issues
> with stops would be non-issues by design...

Yes, this seems more reasonable as well.

Thanks for the review.

Maxime.