This is the mail archive of the
mailing list for the binutils project.
Re: RFC: Collecting together binary file attributes into a single file.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: "Richard Earnshaw (home)" <richard dot earnshaw at buzzard dot freeserve dot co dot uk>, "binutils at sourceware dot org" <binutils at sourceware dot org>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "aph at redhat dot com" <aph at redhat dot com>
- Date: Thu, 29 Sep 2011 15:33:07 +0000 (UTC)
- Subject: Re: RFC: Collecting together binary file attributes into a single file.
- References: <firstname.lastname@example.org> <7466E409-8C17-408C-82C6-E0A1C6AD3D20@buzzard.freeserve.co.uk> <4E847BFD.email@example.com>
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
Joseph S. Myers