Subject: i386 stand/lib/loadfile.c on pmax problems
To: None <tech-kern@netbsd.org>
From: Simon Burge <simonb@netbsd.org>
List: tech-kern
Date: 03/24/1999 14:04:37
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.