Teee hee heee...   I wrote that (originally from the sun3).

The idea was to keep the header whether or not the file format
of the kernel has the a.out header in the text segment or not,
and always load it just before "_start".  When loading an old
OMAGIC or NMAGIC (header not part of text) on the sun3, the
header ends up at LOADADDR-sizeof(header).  I presume that on
the pmax an OMAGIC header should end up at: 0x8002ffe0

Take a look at this file for details: 
/sys/arch/sun3/stand/libsa/exec_sun.c

Gordon

Simon Burge writes:
 > Hi folks,
 > 
 > As some people may be aware, I'm redoing the pmax bootblocks at the
 > moment so that they're now a two-stage affair and use things like the
 > MI libsa.  I'm using the i386 stand/lib/loadfile.c routines to load the
 > kernel, and it works fine for ELF and ECOFF kernels, but the following
 > section of code is killing my a.out kernels:
 > 
 > 	/*
 > 	 * Leave a copy of the exec header before the text.
 > 	 * The kernel may use this to verify that the
 > 	 * symbols were loaded by this boot program.
 > 	 */
 > 	if (flags & LOAD_HDR)
 > 		BCOPY(x, maxp, sizeof(*x));
 > 	if (flags & (LOAD_HDR|COUNT_HDR))
 > 		maxp += sizeof(*x);
 > 
 > On the pmax, entry is 0x80030000, and both "start" and "_kernel_text"
 > are the same value.  If LOAD_HDR is set (I'm passing LOAD_ALL to
 > loadfile()), then the a.out header is saved at 0x80030000, and the
 > kernel text (and hence "start") 0x20 bytes (sizeof(struct aout)) higher.
 > Then we jump to 0x80030000, and of course things don't work very well at
 > all ;)
 > 
 > On the i386, "start" is 0x20 bytes higher than "_kernel_text", and
 > everything is hunky dory.  Without knowing much about the i386, I'm not
 > sure why the two are different. nm -n of a "normal" binary shows "start"
 > at 0x1020, maybe the 0x20 offset is ``magic'' on the i386.
 > 
 > 
 > So, what's the right way to fix this if loadfile.c is to become MI?  My
 > first guess is adding something like:
 > 
 > 	if (maxp != entry) {
 > 		...
 > 	}
 > 
 > around the above section of code, but then we lose the a.out header
 > altogether.  This isn't a huge loss right now, because soon on the
 > pmax (and already on i386 I suspect) we get the kernel symbols from a
 > bootinfo symtab record.  What other ports may do though...
 > 
 > Any suggestions?
 > 
 > Simon.