From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6635 invoked by alias); 31 Jan 2013 17:19:45 -0000 Received: (qmail 6605 invoked by uid 22791); 31 Jan 2013 17:19:42 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,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; Thu, 31 Jan 2013 17:19:35 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0VHJXg3025940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Jan 2013 12:19:33 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r0VHJVCm014931; Thu, 31 Jan 2013 12:19:32 -0500 Message-ID: <510AA7A3.4010702@redhat.com> Date: Thu, 31 Jan 2013 17:19:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Sergio Durigan Junior CC: Binutils Development , GDB Patches , Jan Kratochvil , "H. J. Lu" Subject: Re: [PATCH 1/3] Implement new Linux target vectors on BFD References: <20130130091631.GM3244@bubble.grove.modra.org> 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: 2013-01/txt/msg00758.txt.bz2 On 01/30/2013 04:42 PM, Sergio Durigan Junior wrote: > On Wednesday, January 30 2013, Alan Modra wrote: >> Duplicating targets isn't a really good idea. > Hm, thank you for the explanation, it didn't occurred to me. Indeed. Thanks. >> You may have noticed that we've already made a mess of targets for >> ARM, i386, x86_64 and powerpc. I'd rather not see the same happen for >> powerpc64 without a really good reason. > > Right. Now I am stuck with this, then. While Pedro wants this feature > to be Linux-specific, now there is this problem with target > duplication. It's not about what I want. It's about the fact that different targets/OSs have different prpsinfo etc. structures. > I will look for other solutions here, but if you alreay have some idea > on how to handle it, I'd be glad to read. My idea is to cut the middle man. AFAICS, only GDB wants to generate core files presently. GDB has a whole OS/arch sniffer mechanism in place, where we know which target/arch/OS it is that is being debugged. So rather than having bfd know which prpsinfo layout we want, and shoehorn different elf_internal_prpsinfo & friends structures through the elfcore_write_note/va_args generic interface, skip the bfd vector, and add new entry points in bfd for each possible output, and have GDB pick the one it needs. Since most Linux archs have the same prpsinfo32 and prpsinfo64 layout, we just put the default Linux implementations in elf.c. PPC32, being the odd one out, gets its own implementation. I'll send updated bfd and gdb patches as response to this email. -- Pedro Alves