From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3175 invoked by alias); 5 Jan 2012 15:17:26 -0000 Received: (qmail 3087 invoked by uid 22791); 5 Jan 2012 15:17:24 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,TW_OC,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e06smtp15.uk.ibm.com (HELO e06smtp15.uk.ibm.com) (195.75.94.111) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Jan 2012 15:17:09 +0000 Received: from /spool/local by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 5 Jan 2012 15:17:08 -0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com ([9.149.38.129]) by e06smtp15.uk.ibm.com ([192.168.101.145]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 5 Jan 2012 15:17:02 -0000 Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q05FH2jg2076752 for ; Thu, 5 Jan 2012 15:17:02 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q05FH1CS012077 for ; Thu, 5 Jan 2012 08:17:02 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id q05FH0IE012035; Thu, 5 Jan 2012 08:17:00 -0700 Message-Id: <201201051517.q05FH0IE012035@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 05 Jan 2012 16:17:00 +0100 Subject: [rfc, ping] Remote "info proc" and core file generation To: gdb-patches@sourceware.org, alves.ped@gmail.com Date: Thu, 05 Jan 2012 15:17:00 -0000 From: "Ulrich Weigand" Cc: jan.kratochvil@redhat.com, sergiodj@redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 12010515-0342-0000-0000-00000084DA60 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/msg00191.txt.bz2 Hello, given the problems with my latest attempt to access /proc remotely via generic file access routines documented here: http://sourceware.org/ml/gdb-patches/2011-12/msg00782.html I would like to go back to my earlier approach using TARGET_INFO_PROC: http://sourceware.org/ml/gdb-patches/2011-12/msg00007.html http://sourceware.org/ml/gdb-patches/2011-12/msg00008.html http://sourceware.org/ml/gdb-patches/2011-12/msg00009.html http://sourceware.org/ml/gdb-patches/2011-12/msg00010.html http://sourceware.org/ml/gdb-patches/2011-12/msg00011.html http://sourceware.org/ml/gdb-patches/2011-12/msg00014.html http://sourceware.org/ml/gdb-patches/2011-12/msg00015.html http://sourceware.org/ml/gdb-patches/2011-12/msg00016.html In the meantime, I've got approval for the doc and bfd parts, and Joel has regression-tested the patches on a procfs target (Irix). So the only thing that stops this patch series from going in as-is is consensus that TARGET_INFO_PROC is the right abstraction level. Given the experiments I did in the meantime (see above), I'd now argue that this *is* the proper level of abstraction: - TARGET_INFO_PROC allows the *contents* of Linux /proc files to be passed through unchanged, so we don't have to define our own formats (and keep updating them) -- the one drawback is that the contents are obviously Linux-specific, but that's OK as long as the target objects are only used in linux-tdep code. - At the same time, *access* to those contents is abstracted. This means we do *not* have to know exactly where on the target the /proc files are found: e.g. in the classic remote target, the GDB host side does not even know the PID of the inferior process on the target. (Another possibility might be a Linux kernel remote target that operates via hardware debugging or in-kernel debugging and still provides access to Linux processes: such remote stubs could also implement TARGET_INFO_PROC, even if they may not provide general access to the file system.) Pedro, you had been raising concerns about this initially. Did you have a chance to look at the discussion refered to at the top of this mail? Do you still feel that TARGET_INFO_PROC is inappropiate? Thanks for your feedback on this! Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com