Subject: Re: port-i386/26007
To: None <gavan@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,>
From: Eric Horch <ehorch@gmail.com>
List: netbsd-bugs
Date: 12/08/2005 08:25:02
The following reply was made to PR port-i386/26007; it has been noted by GNATS.

From: Eric Horch <ehorch@gmail.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-i386/26007
Date: Thu, 8 Dec 2005 01:22:17 -0700

 Gavan Fantom wrote:
 > David Laight wrote:
 > >  One difference between the 1.6 bootcode and the current copy is that
 > >  prot_to_real used to do an immediate ljmp having just written to the
 > >  code to patch the instruction.  I changed it to do an indirect longjum=
 p.
 > >
 > >  I don't think anyone has tried reverting that change.
 > >  (Nor the other subtle changes required to get the correct address mode
 > >  and bound bits set in the segment descriptor - IIRC especially SS)
 >
 > Does any other OS do it the way we currently do?
 
 Doesn't look like it.  I checked the other BSDs and two popular Linux
 booters and they all use immediate operands to their far jumps.
 
 Here are a few observations I noted while inspecting those other ones.
 
   1) Most play it conservative and keep real mode cs =3D=3D ds =3D=3D ss =
 =3D=3D 0.
   2) Several use split stacks.  That is, one stack for real mode and
      one for protected, which requires passing items back and forth.
   3) For the ones that use gas and ld, segments tend to be hard coded
      and there are a lot of address fixups in the 16-bit code.
 
 Looking again at our code, I noticed these things.
 
   1) In prot_to_real, the operand to the indirect far jump should
      point to a six-byte object (lower four -> eip, upper two -> cs)
      just like a far return (lret) pops six bytes off the stack
      (for example, see the last few lines of startprog.S).
   2) Adding two bytes to realprot.S makes things worse while adding
      a dozen printfs to boot2.c makes it work on my machine.
 
 The first one appears to be innocuous.  The second one has me thinking
 that something's scribbling in the wrong spot.  Perhaps our stack or
 data areas are not where we think they are and these VIA systems are
 different enough to follow a code path that more normal machines
 don't and therefore they hit the damage.
 
 --
 Eric Horch
 ehorch@gmail.com