From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5797 invoked by alias); 17 Jan 2012 19:37:04 -0000 Received: (qmail 5655 invoked by uid 22791); 17 Jan 2012 19:37:02 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e06smtp14.uk.ibm.com (HELO e06smtp14.uk.ibm.com) (195.75.94.110) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Jan 2012 19:36:49 +0000 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 17 Jan 2012 19:36:46 -0000 Received: from d06nrmr1806.portsmouth.uk.ibm.com ([9.149.39.193]) by e06smtp14.uk.ibm.com ([192.168.101.144]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 17 Jan 2012 19:36:10 -0000 Received: from d06av09.portsmouth.uk.ibm.com (d06av09.portsmouth.uk.ibm.com [9.149.37.250]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q0HJaBqZ2375798 for ; Tue, 17 Jan 2012 19:36:11 GMT Received: from d06av09.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q0HJaAQV027216 for ; Tue, 17 Jan 2012 12:36:10 -0700 Received: from d06ml032.portsmouth.uk.ibm.com (d06ml032.portsmouth.uk.ibm.com [9.149.76.137]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q0HJaARq027213; Tue, 17 Jan 2012 12:36:10 -0700 Received: from tuxmaker.boeblingen.de.ibm.com ([9.152.85.9]) by d06ml032.portsmouth.uk.ibm.com (Lotus Domino Release 8.5.2FP3) with SMTP id 2012011720360335-40701 ; Tue, 17 Jan 2012 20:36:03 +0100 Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 17 Jan 2012 20:36:08 +0100 Subject: Re: [rfc v2][0/6] Remote /proc file access To: palves@redhat.com (Pedro Alves) Date: Tue, 17 Jan 2012 19:41:00 -0000 From: Ulrich Weigand Cc: gdb-patches@sourceware.org In-Reply-To: <4F1461F4.6060702@redhat.com> from "Pedro Alves" at Jan 16, 2012 05:44:20 PM MIME-Version: 1.0 Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii x-cbid: 12011719-1948-0000-0000-000000AA0AA6 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/msg00622.txt.bz2 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. 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 ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com