From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16935 invoked by alias); 18 Jan 2012 11:46:40 -0000 Received: (qmail 16926 invoked by uid 22791); 18 Jan 2012 11:46:40 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 Jan 2012 11:46:26 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0IBk2Ks004029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jan 2012 06:46:02 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q0IBk0AO013165; Wed, 18 Jan 2012 06:46:01 -0500 Message-ID: <4F16B0F8.2020109@redhat.com> Date: Wed, 18 Jan 2012 12:09:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Joel Brobecker CC: Ulrich Weigand , gdb-patches@sourceware.org Subject: Re: [rfc v3][0/6] Remote /proc file access References: <20120118113807.GA31383@adacore.com> In-Reply-To: <20120118113807.GA31383@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2012-01/txt/msg00665.txt.bz2 On 01/18/2012 11:38 AM, Joel Brobecker wrote: > I ran the testsuite on mips-irix, and got one real semi-regression: > > info proc^M > Not supported on this target.^M > (gdb) FAIL: gdb.base/info-proc.exp: info proc without a process > > I think it's just a matter of the output having changed. This looks like caused by the new target method not falling back to the default run target when no target is pushed yet. "info proc PID" must have stopped working too. I guess we should really make it fallback, while we still have the method. > I couldn't verify it completely, because I had lost the gdb.log file from the > reference run (they are now split, and I only saved the top one). > If it wasn't intended, I'd still consider this an improvement since > the expected output was: -- Pedro Alves