This is the mail archive of the
mailing list for the binutils project.
Re: bfd target vector rationalisation
- From: Jeff Law <law at redhat dot com>
- To: binutils at sourceware dot org
- Date: Wed, 30 Apr 2014 09:29:05 -0600
- Subject: Re: bfd target vector rationalisation
- Authentication-results: sourceware.org; auth=none
- References: <20140430143503 dot GE16139 at bubble dot grove dot modra dot org>
On 04/30/14 08:35, Alan Modra wrote:
FWIW, no objections to the hp300bsd changes; it's a dead platform. I
don't recall if I ever contributed the hp200bsd bits, but if you need to
twiddle them, go for it.
This renames the bfd targets to <cpu>_<format>_<other>_<endian>_vec.
So for example, bfd_elf32_ntradlittlemips_vec becomes
mips_elf32_ntrad_le_vec and hp300bsd_vec becomes m68k_aout_hp300bsd_vec.
The idea being to expose the cpu and format in some of the odd target
names like hp300bsd_vec, and to then group target vectors in target.c
and configure.in by cpu after sorting. Hopefully this will help
maintainers notice that some change for a particular target, eg. an
arm-elf testsuite addition, might affect other similar targets,
eg. need adjusting for arm-aout. Sorting isn't done in this patch.
The next patch will do that.
I realize this has the potential to break gdb, sim and other packages
that use bfd, but I think gdb and sim are OK. I know oprofile will
break, and I intend to send a patch to cure that problem. Are there
other packages out there that use bfd, and access target vectors
Similarly for any hp700/hp800/hppa bits.