From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32014 invoked by alias); 10 Sep 2002 14:25:38 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 32002 invoked from network); 10 Sep 2002 14:25:36 -0000 Received: from unknown (HELO valrhona.uglyboxes.com) (64.1.192.220) by sources.redhat.com with SMTP; 10 Sep 2002 14:25:36 -0000 Received: from localhost.localdomain (IDENT:CKefBQlgPJdkw94sPT5+Jq/6bVVeUz0x@localhost.localdomain [127.0.0.1]) by valrhona.uglyboxes.com (8.11.6/8.11.6) with ESMTP id g8AESJJ01611; Tue, 10 Sep 2002 07:28:19 -0700 Date: Tue, 10 Sep 2002 07:25:00 -0000 From: Keith Seitz X-X-Sender: keiths@valrhona.uglyboxes.com To: Elena Zannoni cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/MI testsuite] mi_run_to_main/mi_next/mi_step In-Reply-To: <15741.22284.95937.520608@localhost.redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-09/txt/msg00147.txt.bz2 On Mon, 9 Sep 2002, Elena Zannoni wrote: > Hmmm how does this interact with the mi_next_to, etc, functions that > were added back in November? > the original patch was here: > http://sources.redhat.com/ml/gdb-patches/2001-10/msg00336.html The two pathways are completely independent, although they appear to accomplish the same thing. The stop specification for mi_step/next_to is more stringent, though. This patch just fixes what is already in mi-support.exp, which doesn't work at all. As an alternative, we could whack mi_step and mi_next (or I we could even re-write those to use mi_step_to and mi_next_to, come to think of it). Keith