From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17349 invoked by alias); 29 Sep 2011 15:33:29 -0000 Received: (qmail 17332 invoked by uid 22791); 29 Sep 2011 15:33:28 -0000 X-SWARE-Spam-Status: No, hits=-1.7 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; Thu, 29 Sep 2011 15:33:12 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1R9Ibm-00065q-Pr from joseph_myers@mentor.com ; Thu, 29 Sep 2011 08:33:10 -0700 Received: from digraph.polyomino.org.uk ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Sep 2011 16:33:09 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.74) (envelope-from ) id 1R9Ibj-0007Me-VE; Thu, 29 Sep 2011 15:33:07 +0000 Date: Thu, 29 Sep 2011 17:57:00 -0000 From: "Joseph S. Myers" To: Nick Clifton cc: "Richard Earnshaw (home)" , "binutils@sourceware.org" , "gdb-patches@sourceware.org" , "gcc@gcc.gnu.org" , "aph@redhat.com" Subject: Re: RFC: Collecting together binary file attributes into a single file. In-Reply-To: <4E847BFD.1000807@redhat.com> Message-ID: References: <7466E409-8C17-408C-82C6-E0A1C6AD3D20@buzzard.freeserve.co.uk> <4E847BFD.1000807@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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-09/txt/msg00550.txt.bz2 On Thu, 29 Sep 2011, Nick Clifton wrote: > Hi Richard, > > > I don't think it's a good idea to have the attributes of > > every CPU we support in a single file. That's going to > > get unmaintainable very quickly. > > Really - why ? > > These attributes are mostly static. Some new ones might be added from time to > time, but baring the introduction of new ports I do not see any other changes > that re likely to happen. Among other things, it's quite possible that two targets will have names (defined in their ABIs) that conflict. And the patch appears to be duplicating the C6X definitions (also present in tic6x-attrs.h for use in places that want to build an array as well as those just defining an enum) which is hardly desirable. If you want a shared header *for ARM EABI attributes*, defining a header restricted just to the required definitions (and making sure everything relevant uses it) seems reasonable. Now, all the definitions get included at once in readelf.c, so any conflicts would be visible there, but really I don't think that's a good design. Rather than all those hardcoded switch statements I think it would be better to have e.g. readelf-arm.c that defines the ARM-specific functions and data (with readelf.c looking up function pointers in a structure exported by each architecture's file and identified by the e_machine value rather than using a switch statement in each place). You might then have just one array that contains pointers to all the target structures. -- Joseph S. Myers joseph@codesourcery.com