Date: Wed, 2 Sep 1998 07:57:18 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dawes@rf900.physics.usyd.edu.au (David Dawes) Cc: mike@smith.net.au, tlambert@primenet.com, jb@cimlogic.com.au, freebsd-current@FreeBSD.ORG Subject: Re: Standardizing a BSD/ELF ABI... Message-ID: <199809020757.AAA24402@usr02.primenet.com> In-Reply-To: <19980902131453.C21469@rf900.physics.usyd.edu.au> from "David Dawes" at Sep 2, 98 01:14:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Is there compatibility for dynamically linked executables when using the > runtime host platform's native libraries? Yes and no. ELF supports the idea of multiple, seperate data segments. Using this construct, one can finally build shared libraries where the data section of a shared libraries static, initialized data comes from the dynamically linked shared library in the load phase rather than the link phase. If you want to get into details: any program distribured for Linux at this time FAILS the LGPL relink clause because the data segment is linked into the program image from the shared library at the time the program is linked, and runtime relinking applies only to code, not to data. It is easy to implement a data-content dependent example of a library that fails the LGPL relink clause because of this. Techinically, one need only increase the size of a statically initialized data area. Read the Dejanews archives of gnu.misc.discuss; Richard Stallman has specifically refused to address the state of shared library technology inre: the LGPL, despite numerous challenges, many from myself or from others which have noted this discrepancy in the LGPL relink clause. To implement this correctly, one must seperately map the data segments of the LGPL shared library and of the program linked against the shared library. The result is that the COW data segments are not reloacted until runtime, and any libray dependent data is taken from the library image at load time instead of the statically linked shared library data segment of the shared library present at link time. So... there are cases where the resulting binary will fail when dynamically linked. I have counted three instances of this occurring in Linux (RedHat) during the time I have been watching for such ocurrances. Commercial porters to Linuc could, under the terms of the LGPL, be required to supply a relinkable object. This isn't as bad as it sounds -- ld -r will save your internal functunal structure for exposure, should such a demand surface, but it is a PITA to have to eat this risk if you are a commercial vendor who has examined the precise consequences of shared library technology in Linux as it presently stands. In the bigger picture, if the statically initialized data from the shared library is take from a seperately names ELF segment within the shared library (as it should be), then the terms of the LGPL are satisfied in all cases, at least where the data is not externally and promiscuously accessed to provide information to the library. The old libtermcap has this type of access for rows/coulmns (lines, cols) using extern references to library data from user code to handle SIGWINCH, in fact. It is easy to be careful about this, however, since such interfaces break functional abstractions and are, in fact, more than a little anti-portable-code. So assume all of these issues are addressed; what then? In addition to the implicit dependencies between data and code (which MUST be addressed, IMO, and will introduce an incompatibility until the non-implementing parties catch up with the implementing parties), there are issues of manifest constants in header files. Currently, there is no standard for manifest constant values, short of IBCS2 (which neither BSD or Linux implement fully, since it includes issues of install tools an rc.d formats for post-installation start-up and shut-down ordering). This means that the ioctl() values for "cmd" and "args" are not specifically defined (among other things), and that you can not reasonable expect the code to work, even if the call gate mechanism is glossed over by the use of native libraries to invoke system calls: the system call arguments are different. I (personally) believe that the canonically corect way to handle this is to pick an existing commercial standard (for which you would be able to run their commercial binaries), and to implement to that standard. The two available appear to be Solaris and UnixWare. After implementing this, you document the minimal ABI. Then you *further* add a mechanism whereby you can *turn off* all but the minimal ABI. At that point, whatever Open Source UNIX clone implements this becomes the single commercial porting base, since it guarantees a larger market: it is guaranteed that code written for the UNIX clone with vendor extensions disabled will work on both the UNIX clone *AND* on the commercial system which is "level 2 compliant" with the standard (ie: it is defacto defined as such; "level 1 compliant" means you can disable vendor extensions in the OS, and thus guarantee the resulting code will run on all level 1 and level 2 compliant platforms). By definition, you would be an idiot to port any code to anything other than a "level 1, extensions disabled" platform, since you would be limiting your market. The ABI would be defined not only by the ability to choose a native shared library to get both code and data, at load time for both, but by all "non-vendor-extension" parameters to system calls, guaranteed to be the same across platforms. Note that I tried to push this idea long before "86'Open" tried to foist the Linux-ABI-Du-Jour on everyone (unrealistic; commercial vendors do not rev their ABI as frequently as Linux). I called the idea "FABIO", for "Free Application Binary Interface Objective". IMO, it's the only way for UNIX to unite against Microsoft, and thereby stand a chance of not suffering attrition due to in-fighting. Anyway, the short answer would be "No", if you were pointy-haired and partial to short answers instead of correct answers... 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809020757.AAA24402>