Matthias Pfaller writes:
 > Ian Dall wrote:
 > > This glosses over one thing. Dynamic linking. The FSF binutils doesn't
 > > have support dynamic linking on the ns32k. I've had a look a few times at
 > > the changes made to support dynamic linking in the old binutils branch
 > > used by NetBSD, but I've never fully understood them.

I realized there is something I didn't explain very well. Although gas
and binutils all work on the internal bdf representation, there are
none the less machine dependent operations. A port includes providing
call back functions to implement those machine dependant functions,
generally with a default.

So, although there is dynamic linking support already in binutils,
there may need to be ns32k specific functions, or modifications to the
existing ns32k specific functions to support dynamic linking. As well
as the read and write functionality I mentioned.

Although the NetBSD binutils 1 is an instance of the functionality
needed for dynamic linking on the ns32k, the actual code would not be
easy to translate because binutils 1 was prior to the bdf way of doing
things, and the differences are quite significant.

 > > I suspect not that much is needed, but as usual, the problem is
 > > knowing what. I think we link to global symbols in shared objects by
 > > fiddling entires in a global offset table, at run time. I think they
 > > will all be straight two's complement numbers so the ns32k's ah
 > > richness doesn't bite. What I don't understand is what the
 > > pre-exisiting elf relocation types are, and which ones match the ns32k
 > > types and what needs to be ns32k specific.
 > 
 > That's more or less where I gave up (mostly due to lack of energy).
 > In order to support dynamic linking one has to hack gas as well.

And maybe even some gcc changes, perhaps only the debugging stuff.

Ian