Date: Sat, 19 Sep 1998 05:24:18 +0200 (SAT) From: Robert Nordier <rnordier@nordier.com> To: cyouse@artemis.syncom.net (Charles Youse) Cc: bf20761@binghamton.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: PC memory usage (what is PIC?) Message-ID: <199809190324.FAA12252@ceia.nordier.com> In-Reply-To: <Pine.NEB.3.96.980918183750.9143A-100000@artemis.syncom.net> from Charles Youse at "Sep 18, 98 06:53:50 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Charles Youse wrote:
> On Fri, 18 Sep 1998, zhihuizhang wrote:
>
> > Since it has been linked for another (high) address, it will have to
> > execute PIC until the page table and page directory stuff is setup
> > properly, at which point paging will be enabled and the kernel will
> > finally run at the address for which it was linked.
> >
> > Can anyone explain to me what is PIC and the two different linked
> > addresses mentioned here?
In the standard i386 kernel, the first few hundred bytes of startup code
execute at 0x100000 before the virtual address changes to 0xf0100000
(though the code remains at the same physical location).
>
> PIC refers to Position-Independent Code, which requires that all
> references to memory be relative to the IP register. Code written in
> this way will execute correctly no matter where it is loaded into the
> address space.
Actually, calling the kernel startup code PIC is a merely a convenient
distortion of the truth, at least as far as the i386 FreeBSD kernel
startup is concerned.
Writing truly IP-independent i386 assembly code by hand (and the initial
portion is pure assembly code), requires completely unnatural practices.
> Because the kernel is linked to run at a different address than it's
> loaded, references to absolute addresses will fetch invalid data from
> a [nonexistent] random memory location. The solution is to restrict
> the kernel to PIC (which has no such absolute references) until the
> vm subsystem is initialized to redirect those absolute [virtual]
> addresses to the proper physical addresses.
The actual i386 solution is to pre-bias each actual absolute address
reference in the initial startup section. This macros is used:
#define R(foo) ((foo)-KERNBASE)
The resultant code is not really position-independent in any sense, but
it is correct for its execution address.
--
Robert Nordier
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809190324.FAA12252>