Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!umd5.umd.edu!roissy.umd.edu!mark From: mark@roissy.umd.edu (Mark Sienkiewicz) Newsgroups: comp.os.386bsd.development Subject: Re: Shared libraries and 386bsd. Date: 24 Mar 1993 20:18:11 GMT Organization: University of Maryland Lines: 112 Message-ID: <1oqfm3$i6q@umd5.umd.edu> References: <MCKIM.93Mar23082603@dinah.lerc.nasa.gov> <1onp3o$l3v@umd5.umd.edu> <33426@castle.ed.ac.uk> NNTP-Posting-Host: roissy.umd.edu >From: richard@castle.ed.ac.uk (Richard Tobin) >>The 386 has segment registers. > >Noooo... please, not that... > >Anything that results in non-uniform pointers, even if they're only >code pointers, is too high a price to pay. I agree that segment registers are pretty gross, but they probably work. Actually, I don't have any reason to belive that segmenting in 32 bit mode has been well tested. Why would anybody bother? I would also agree with the claim that the only reason DOS users use segments is because they _have_ to to make anything reasonable. >From: peter@NeoSoft.com (Peter da Silva) >How do you handle callbacks from a library (big deal in X, but also important >in qsort() and other base routines. probably something like "call far 0:addr". This assumes that function pointers can only point into the application program. Another possibility is to make code pointers be 6 bytes instead of 4. I think it is _not_ a good idea to have this large/small model stuff that Intel promotes. >From: veit@mururoa.gmd.de (Holger Veit) >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 Yes, this is true. Actually, you might keep the original 4G address space and have non-0 segments point into it at various offsets. Then you page it as a single address space, but can access it through different segments. At that point, you might call them "base registers" instead of "segment registers". >|> 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, Not necessarily. I may be advocating a stub library that does the far call for you, that way you can easily allocate whatever segment is available. In this next section, I was talking about two different things: >|> 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. I'm aware that local variables only is a severe restriction. I'm pointing out that it is probably easier than dealing with data segments. Even with data segments, we may be able to come up with some _simple_ way to make it work. For example, maybe there can be a function that looks up a data pointer based on your code segment register. Then you could allocate a block of memory for the library to use as "global" space. >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. I agree with this. Machines with a lot of registers and efficient PIC are also easier to handle. Since the 386 has certain limitations, I'm willing to _consider_ using it's more bizzare features to overcome them. >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. If you mean that the application shouldn't have to do it's own paging, I agree. If you are saying the application should not have to understand it's own data, then I disagree. >|> (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. I'm suggesting using a feature of the hardware (segmenting) to support a feature of software that _does_not_exist_. There is another thought that is not quite clearly expressed in the above discussion, so I will explictly state it here: I think that a shared library may be made responsible for handling issues that result from it being a shared library. I do NOT expect that a shared library can be made by simply converting libfoo.a into libfoo.sl -- I expect there will need to be _some_ code changes. _How_much_ code to change is an issue, but I expect there will be some. Also, I'm not advocating that segmenting is _the_ way to implement shared libraries. I am advocating that it is worth _considering_. Mark S.