"Perry E. Metzger" <perry@wasabisystems.com> writes:

  > Phil Budne <phil@ultimate.com> writes:
  >> Can you outline the tasks involved?  

  > 1) Make the new toolchain (and maybe even gcc current) not break on
  >    the 32k support (which is currently broken)
  > 2) Design and implement the ELF support for 32k.

  >> I seem to recall one issue was there might be architecture
  >> dependant ELF extensions required, and no vendor has done
  >> that for the 32k...

  > That's not much of an issue. You can just invent 32k ELF the way that
  > Matt Thomas invented ELF for the VAX so we could have VAX ELF.

You can invent a ns32k magic number, but that is not the hard bit!
The ns32k needs extra relocation types to distinguish between three
kinds of constants in its operands, immediate, absolute and
displacement. I did the ns32k code in binutils 2.x for that for the
a.out case, but the current binutils doesn't support PIC or ELF for
the ns32k. I'd have done it long ago if I understood these two things!

  >> Another was that the gcc used by the majority of the ports
  >> didn't work for the 32k...

  > That's the big problem -- the new toolchain breaks for unknown reasons
  > on the 32k.

The biggest problem is ELF. I expect most of the gcc problems to be
fixed in gcc 3.0.x (I did considerable work leading up to the gcc 3.0
release, but never checked the final result). Leading up to gcc 3.0
release, the problems where a mixture of machine independent and
machine dependent so back porting those changes to a slightly older
gcc is likely to be problematic. So we would really need the port to use
gcc-current and I am not sure how stable that is.

I am happy to continue working on gcc. If someone else is happy to
pick up the ELF stuff and the kernel stuff.

Ian