Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!convex!convex!darwin.sura.net!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!gmd.de!mururoa!veit
From: veit@mururoa.gmd.de (Holger Veit)
Subject: Re: Shared libraries and 386bsd.
Message-ID: <1993Mar24.102153.22974@gmd.de>
Sender: veit@mururoa (Holger Veit)
Nntp-Posting-Host: mururoa.gmd.de
Organization: GMD - German National Research Center for Computer Science
References: <1993Mar15.064119.19323@hippo.ru.ac.za> <MCKIM.93Mar23082603@dinah.lerc.nasa.gov> <1onp3o$l3v@umd5.umd.edu>
Date: Wed, 24 Mar 1993 10:21:53 GMT
Lines: 65
In article <1onp3o$l3v@umd5.umd.edu>, mark@elea.umd.edu (Mark Sienkiewicz) writes:
|> In article <MCKIM.93Mar23082603@dinah.lerc.nasa.gov> mckim@dinah.lerc.nasa.gov (Jim McKim) writes:
|> >
|> >There is partial support in gcc for pic code.
|> >Some enhancements will have to be made to the assembler.
|> >
[...]
|> There's another spooky possibility...
|>
|> The 386 has segment registers.
|>
|> (go ahead -- flame away :)
|>
|> If you placed each shared library in it's own segment, you could link the
|> library based at 0 and avoid some of the PIC problems. You pay for it
|> by dealing with the segmentation stuff.
Good idae, but:
The whole BSD code is still derived from the (non-segmenting) paging architecture
of the ol' VAX. There is significant work to do in the kernel, as well as the
loader and the way of gcc code generation, to get the segments back (of course
not the 64K ones ;-)). I wouldn't dare to implement it; it looks like real hard
work :-).
|> If you give each library it's own code segment, it doesn't need to be position
|> independent code. You still need to handle data.
Do you advocate for reserving segment numbers for libraries, say segment 0x100
for libc, 0x104 for libX11, etc.? This comes close to the fixed address approach,
which is already existing and was done without segmentation. The disadvantage
is known as address space pollution, probably causing address clashes.
|> If you give each library it's own data segment, you don't need to handle
|> position independent data, but you _do_ need to worry about which segment
|> pointers point into, etc. If you write your library to use only local
|> variables and dynamically allocated memory, you don't even need to have
|> a data segment for it.
Using local variables only is a severe restriction, and is impossible for
the existing libraries that are the first target for becoming shared.
Messing around with different segments, and intersegment calls and intersegment
data access requires additional code for dealing with the segment registers,
similar to what is known from DOS. The flat address space model is much easier to
handle. It shouldn't be the task of an application to take care where to find
its data and addresses. Once it is loaded into memory, it is the job of the kernel
to guarantee that everything which is needed is (transparently) there.
|>
|> (We have all this brain-damaged segmenting stuff hanging around anyway... maybe
|> we can use it for something.)
Segmenting on 386 is not as brain-damaged as the 8086 DOS stuff made it.
But I think changing a (mainly) working thing for the sake of using a feature
of the processor is not a good idea.
|>
|> Mark S.
--
Dr. Holger Veit | INTERNET: Holger.Veit@gmd.de
| | / GMD-SET German National Research | Phone: (+49) 2241 14 2448
|__| / Center for Computer Science | Fax: (+49) 2241 14 2342
| | / P.O. Box 13 16 | Three lines Signature space
| |/ Schloss Birlinghoven | available for rent. Nearly
DW-5205 St. Augustin, Germany | unused, good conditions