From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13328 invoked by alias); 9 Dec 2011 13:49:37 -0000 Received: (qmail 13317 invoked by uid 22791); 9 Dec 2011 13:49:36 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 09 Dec 2011 13:49:23 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RZ0pF-00050z-36 from pedro_alves@mentor.com ; Fri, 09 Dec 2011 05:49:21 -0800 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Dec 2011 13:49:19 +0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [rfc] Options for "info mappings" etc. (Re: [PATCH] Implement new `info core mappings' command) Date: Fri, 09 Dec 2011 14:10:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-13-generic; KDE/4.7.2; x86_64; ; ) Cc: "Ulrich Weigand" , jan.kratochvil@redhat.com, sergiodj@redhat.com References: <201112071755.pB7HtTK3024601@d06av02.portsmouth.uk.ibm.com> <201112091256.41787.pedro@codesourcery.com> In-Reply-To: <201112091256.41787.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201112091349.17658.pedro@codesourcery.com> X-IsSubscribed: yes 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: 2011-12/txt/msg00286.txt.bz2 On Friday 09 December 2011 12:56:41, Pedro Alves wrote: > > The alternative to TARGET_OBJECT_FILE/SYMLINK would be to provide a set > > of target_file_... accessor routines that map to native IO for native > > targets and hostio for remote targets, again with a gdbarch option to > > synthesize file contents from core files. > > Right, that's what my "alternatively, wrap the hostio mechanism in a > ui-file (through open/read/write/close/... target methods perhaps), and > use that." comment aluded to. Since you'd need to keep a reference > to an open handle to a file somewhere, I thought ui-file could be good > for that. The core target could just use mem_fileopen() to return an > in-memory ui-file with the synthetic /proc/PID/... contents. I guess > we'd need a new symlink ui-file type too. Actually looking at the remote_bfd_iovec_open, remote_bfd_iovec_pread, etc., an ui-file would probably be unnecessary and overkill. The target methods can just work on the file descriptor (as you were probably thinking). That'd mean the core target's implementation would need to manage it's own little list of open file handles, though. -- Pedro Alves