From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4877 invoked by alias); 11 Jan 2013 15:45:45 -0000 Received: (qmail 4857 invoked by uid 22791); 11 Jan 2013 15:45:43 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Fri, 11 Jan 2013 15:45:37 +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 r0BFjaoY011372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jan 2013 10:45:36 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r0BFjYmP031473; Fri, 11 Jan 2013 10:45:35 -0500 Message-ID: <50F0339E.5070206@redhat.com> Date: Fri, 11 Jan 2013 15:45:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Sergio Durigan Junior CC: Jan Kratochvil , Binutils Development , GDB Patches , "H.J. Lu" Subject: Re: [PATCH/RFC 01/02 v2] Refactor PRPSINFO handling on Binutils References: <20121218173747.GA24546@host2.jankratochvil.net> <20121218193104.GA29194@host2.jankratochvil.net> <20130101143027.GA17408@host2.jankratochvil.net> <20130103134431.GA4099@host2.jankratochvil.net> <50EF07C8.3050307@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2013-01/txt/msg00173.txt.bz2 On 01/10/2013 07:47 PM, Sergio Durigan Junior wrote: >> On 01/04/2013 04:39 AM, Sergio Durigan Junior wrote:> +++ b/bfd/elf-psinfo.h >>> @@ -0,0 +1,124 @@ >>> +/* Definitions for PRPSINFO structures under ELF on GNU/Linux. >> >> What about other OSs, like e.g., Solaris? > > Since I took the definitions from the Linux kernel, I thought it'd be > better to explicitly mention that. I'm afraid I don't know how Solaris > handle corefiles, do you think this comment should be expanded? It's not that different on other Unixen, but the structures may be different. But I'm actually pondering about is whether we're tying the whole new interface to Linux, causing problems for converting other non-Linux ports. E.g., a quick websearch for prpsinfo finds: http://bintree.net/freebsd/d0/ddc/sys_2procfs_8h_source.html 00075 typedef struct prpsinfo { 00076 int pr_version; /* Version number of struct (1) */ 00077 size_t pr_psinfosz; /* sizeof(prpsinfo_t) (1) */ 00078 char pr_fname[PRFNAMESZ+1]; /* Command name, null terminated (1) */ 00079 char pr_psargs[PRARGSZ+1]; /* Arguments, null terminated (1) */ 00080 } prpsinfo_t; Other BSDs are probably similar, Solaris, IRIX, etc., will probably have a different structure in their own ways. So indeed it looks like there's a problem here, and I think these differences need to be contemplated. How is the question. One way would be for the hook to still take a "struct elf_internal_prpsinfo" pointer, but make it so that "struct elf_internal_prpsinfo" itself is opaque to the common code. Both GDB's core generator code, and then bfd's elf_backend_write_core_note hook would then have to agree on what the type of "struct elf_internal_prpsinfo" really is, and either cast appropriately (e.g., to/from struct elf_linux_internal_prpsinfo), or including a file that has the proper definition of "struct elf_internal_prpsinfo" for the target (I think that violates C++'s ODR, so I tend to dislike it, although gdb/binutils do this for other similar cases). This is largely what the patch does already, except it takes no consideration, either in naming or in comments that "struct elf_internal_prpsinfo" is Linux specific, giving the impression that it'd work for all ports. But it doesn't look like it would. E.g., elf64-x86-64.c:elf_x86_64_write_core_note with the patch is always using the Linux specific structure. We need to instead have a Linux-specific version of that hook; comments at the top of the file show it's used with FreeBSD and Solaris too as well, and those will need their own versions (could be the current pre-patch version). Etc. -- Pedro Alves