Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!umd5.umd.edu!elea.umd.edu!mark From: mark@elea.umd.edu (Mark Sienkiewicz) Newsgroups: comp.os.386bsd.development Subject: Re: Shared libraries and 386bsd. Date: 23 Mar 1993 19:40:40 GMT Organization: University of Maryland Lines: 33 Message-ID: <1onp3o$l3v@umd5.umd.edu> References: <1993Mar15.064119.19323@hippo.ru.ac.za> <MCKIM.93Mar23082603@dinah.lerc.nasa.gov> NNTP-Posting-Host: elea.umd.edu 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. > >One additional caveat - it looks like gcc sacrifices the ebx register >to the cause when pic is used. The 386 architecture isn't real good at >supporting pic operations. Since it doesn't have that many registers, >I wonder what the effect on performance is. 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. 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. 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. (We have all this brain-damaged segmenting stuff hanging around anyway... maybe we can use it for something.) Mark S.