Re: Proposed targets to obsolete for gcc 3.5

Phil Budne <[email protected]> writes:

> Ian wrote:
> > Similar comments about the gas and binutils ports. We have a
> > functioning a.out port (albeit without dynamic linking), there are
> > plenty of examples of elf ports (vax is probably a good starting
> > place). But someone has to get there head around it all, understand
> > elf and the organization of binutils (the way macros are used is not
> > transparent) do the coding test it debug it etc.
> 
> I'd be interested in doing ELF work, tho help from someone who
> understands the issues (I seem to recall the 32k needed something
> (24-bit relocatables?) that VAXen don't use).  I'd be MUCH more likely
> to do actual work if it can be done cross compiling on x86.

I'd start from a recent FSF distribution (or current CVS even) rather than
work in the NetBSD tree initially. That can definitiely be built as cross
tools.

The ns32k has three kinds of constants which could need relocating.
Ordinary little endian two's compliment representation. This pops up
in things like jump tables. Displacements, which are big-endian
huffman coded and immediate values which are big endian twos
complement. You really have to stretch to think of a reason why
immediate values could need relocating and maybe this case could be
ignored.  The 24 bits is just to do with the way the relocation types
and another quantity (an offset?) need to be coded in 32 bits to
conform with the a.out layout. A few extra bits were needed for the
ns32k, which shrank the size of the other bit. This should be
irrelevant to elf.

In anycase, this shouldn't be too hard. Everything works on a bdf
internal represnentation. The external representation (a.ount, elf
etc) is read into an internal bdf representation which is supposed to
be independent of external format, though the ideal is not quite
there. Once in internal format, in principle nothing should care what
format it is. So, the code to generate bdf (in gas) is there, the code
to relocate and link bdf is there. What is missing is code to read
ns32k-elf into bdf representation and write bdf in ns32k-elf
representation. The functions for doing relocation shouldn't need to
change. What will need to be done is decide on codes for ns32k
specific relocation types and write some code to read and write them.
Also a magic number to identify ns32k-elf files, but I think someone
got a number allocated.

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 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. The elf spec is available
on-line somewhere I think. Try google.  I have a downloaded copy
(which is a bit old). Sing out if you want me to send it.

One thing the binutils suite should be able to do is link a.out into
an elf output file. Look also at objcopy, objdump etc. This might be
useful in the early debugging stages. Start with a small working aout
program. Link the aout objects into an elf executable (this may not
work with everything). Look at the generated executable, disassemble
it if necessary. Once you have something working it gets easier.

> Last time I looked at this I ended up stuck in a quagmire of NetBSD
> configuration and different versions of binutils!

I'd start with a recent (say inside the last 12 months) FSF
distribution.

Ian