Andrew Cagney <cagney@highland.com.au> writes:

  > Excerpts from mail: 27-Oct-94 Is the NetBSD.ns32k bfd bac.. Ian
  > Dall@HFRD.DSTO.GOV.A (1748)

  > The reason for posting this is that I'm cleaning up all the NetBSD
  > BFD stuff (should that be fixing up? you mentioned that Cygnus has
  > already cleaned things :-) to use a common *correct* header file
  > (the file netbsd.h was wrong).  So far I've done i386 and PowerPC
  > and am eyeballing the others (hence my mail).
  >
  > I'd like to be able to merge your changes with mine.

I think they looked at my stuff, compared it with the non-working
i386 netbsd stuff, said one of them must be wrong, and changed
the ns32k netbsd support to be like the non-working i386 code!

I have put some patches available for anonymous ftp:

  augean.eleceng.adelaide.edu.au:pub/gnu/ns32k/binutils-2.5.1*

There are three files:

  binutils-2.5.1-new-files.tar.gz	These are files which somehow went
					missing. They are all quite small
					config files.

  binutils-2.5.1-changed-files.tar.gz   These are new versions of files which
					have changed.

  binutils-2.5.1-diffs.gz		This is diffs between the changed files
					and the originals.

This is a bit in-elegant and if you (Andrew) can integrate the netbsd
support with the cleaned up netbsd stuff you did, that would be good.

I am advertising this more widely incase anyone wants to use it. It
*does* work although for the netbsd case, it hasn't been extensively
tested. I can link executeables which run under netbsd, I can objdump
-d existing executeables (quite a good check of lots of the bfd code).

I haven't tried linking netbsd objects or libraries, but in the case of
OMAGIC, the pc532mach and netbsd532 formats are essentially the same,
so I wouldn't expect any problem.

To anyone working on the ns32k support (either netbsd or pc532mach):

The main problem with the 2.5.1 distribution is that the NAME macro is
not defined in ns32knetbsd.c or pc532-mach.c. This is essential otherwise
the bfd_xxx_vec gets initialized with pointers to the wrong function.
The NAME macro must be defined the same as in aout-ns32k.c. I did have
an include file aout-ns32k.h to export the interface to aout-ns32k.c
but the maintainers deleted it. It also had some useful but not essential
prototypes. I thought this was good coding practice, but evidently
the maintainers didn't.

The second big problem is that netbsd.h is just plain wrong most of
the time.  Andrew has addressed that.

The third class of problem is that a number of minor configuration
files either didn't make it into the distribution or had the wrong
names (presumably a new convention was adopted in configure but not
reflected in the file names or visa versa.

Ian