Simon Burge <simonb@wasabisystems.com> writes:

  > The biggest problems I've seen so far are the "spill register overflow"
  > errors reported here in the past.

Yes. I've never (well not for a *long* time) seen it generate bad
code.  It did however *fail* to generate code. Unfortunately, the
register allocator is probably the most opaque bit of code in the
whole compiler. It also relies on heuristics and (it seems to me), that
there is no guarantee that even for a machine with lots of registers,
that there are not cases where the allocator fails.  Also, the interaction
between the machine description and the register allocator is not
obvious.

The plus side is that this is an area which had a lot of work on it
(not much by me) leading up to gcc 3 release. As I reported in the
past, register allocation failure bugs would not so much come and go
as move around from snapshot to snapshot. I'm hopeful that allocator
was stable by the time of the actual 3.0 release.

  > tree here, I'll see if the errors have gone.  Note that even with the
  > old toolchain I see the occasional "spill register overflow" error
  > compiling some kernel files (an IPSEC one comes to mind, that is not
  > enabled by a default pc532 GENERIC kernel).

If you can send me offending code, I'd appreciate it. It would make my
job easier if you can look at the output from make to get the exact
failing compile command. Change "-c" to "-E" and add "-o foo.i" 
(or change the existing "-o foo.o" to "-o foo.i") and send me the
foo.i file. Compress it if it is big. If you feel up to it it would
also help to eliminate code until you have near the minimum which will
demonstrate the failure.

I personally find that the quickest way to trim down the code is to
work on the .i file. Remove all the blank lines. Eliminate whole
functions (or replace them with skeletons) until you have just the
function which causes the problem. Check by just running cc1.

  > I'll be happy to look into ELF and the SA stuff if we have a working
  > toolchain :-)

Ah, but thats why we want ELF, for the toolchain!

The best bet is to either build as cross assembler/linker or build
using the old (circa NetBSD 1.5) toolchain. I'd personally do the
former.

The kernel also presumably needs mods to load ELF files, but I am
betting that this is almost completely machine independent code.

Ian