From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14123 invoked by alias); 17 Jan 2012 19:42:24 -0000 Received: (qmail 14005 invoked by uid 22791); 17 Jan 2012 19:42:23 -0000 X-SWARE-Spam-Status: No, hits=-6.7 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; Tue, 17 Jan 2012 19:42:06 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0HJg4bS019906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Jan 2012 14:42:04 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q0HJg2ME029216; Tue, 17 Jan 2012 14:42:03 -0500 Message-ID: <4F15CF0A.2030909@redhat.com> Date: Tue, 17 Jan 2012 19:46: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: Ulrich Weigand CC: gdb-patches@sourceware.org Subject: Re: [rfc v2][0/6] Remote /proc file access References: In-Reply-To: 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/msg00625.txt.bz2 On 01/17/2012 07:36 PM, Ulrich Weigand wrote: > Pedro Alves wrote: >> On 01/16/2012 05:28 PM, Ulrich Weigand wrote: >>> Maybe. On the other hand, once we've switched to the gdbarch based >>> implementation, it would automatically work when not yet debugging >>> a process anyway, so I'm not sure this is really necessary ... >> >> Hmm. I though the target_file_xxx routines would all fail, hitting the default >> when no target implement the methods that way. IOW, I was thinking that we'd >> need to pass the struct target_ops pointer down to the gdbarch callback so >> the callback could work with the correct target. > > I'd really prefer the gdbarch callback to stand alone; longer term I think > we ought to get rid of target_info_proc completely and have it just always > use the gdbarch callback. Ah. Yes, agreed. > > However, you're right that the target_fileio_ routines fail. I've now fixed > this by making those fall back to the native target if we're not yet connected > to any actual target (>= process_stratum), just like it is already done for > target_get_osdata ... Great, thanks! -- Pedro Alves