In trying to track down why mdsetimage(1) was writing to the wrong spot in
my kernels -- exactly 8K (1 page) before -- I stumbled across the
following:

#define	N_TXTADDR(ex)	(N_GETMAGIC2(ex) == (ZMAGIC|0x10000) ? 0 : __LDPGSZ)

Can anyone explain why N_TXTADDR claims that my NMAGIC kernel text should
load at __LDPGSZ rather than 0 (when I know the latter is really the case,
as it's set with a -Ttext option when linking)?  The reason this comes up
is because in order to find a file offset to write to, mdsetimage(1) uses
something similar to this:

	offset = vmaddr - N_DATADDR(ep) + N_DATOFF(ep);

N_DATADDR depends on N_TXTADDR being correct, and in this case it's
certainly not.  For what it's worth, gdb also has the same trouble on my
mac68k kernels, offsetting the address of symbols in the data segment by
(-__LDPGSZ).

Does anyone see a way out of this fine little mess, other than dumping
a.out?  It seems to me like any time you use -Ttext to set the text start
address, you squash your ability to use mdsetimage(1) on the resulting
kernel...

--scott