Date: Fri, 06 Dec 1996 19:36:26 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: "Martin v.Loewis" <loewis@cs.tu-berlin.de> Cc: pgiffuni@fps.biblos.unal.edu.co (Pedro Giffuni S.), freebsd-emulation@FreeBSD.org Subject: Re: status of windows, dos and svr4 emulation Message-ID: <19746.849929786@time.cdrom.com> In-Reply-To: Your message of "Sat, 07 Dec 1996 01:06:48 %2B0100." <199612070006.BAA02982@cent.cs.tu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> Out of curiosity, can somebody explain (or point me to) what exactly makes
> the FreeBSD a.out superior to similar formats found on other systems?
I don't think that anyone claimed them to be necessarily "superior",
though it's my understanding that loading your typical ELF binary is a
somewhat more expensive (in terms of overhead) exercise than the
lighter a.out ones, so that would be a point in our favor. On the
other hand, ELF is more friendly to things like C++ {cons,des}tructors
and extended debugging information, so it all depends on what your
emphasis is. In the future, we will probably offer folks the option
to either build a.out or ELF executables under FreeBSD depending on
whether they'd prefer activation speed or ELF's extra features.
What people *have* said consistently is that there's no overriding
reason for FreeBSD to go unilaterally to ELF since its shared library
scheme never suffered from the problems the original Linux scheme one
did (and which most Linux folks were strongly in favor of dumping), so
the "transition shock" would be something we'd have no real
justification for.
> - How does it deal with relocation in shared libraries? Does it require
> the shared libraries to be at a fixed address? If not, does it relocate
> the image? If so, is the sharing among different processes preserved?
I don't understand the scheme in as much detail as I'd like, but my
understanding is that a global table of indirect references for each
process is maintained, and on first reference to a shared symbol, the
code in ld.so (which is mapped into the address space at activation
time) will mmap() in the appropriate shared library, if it hasn't
already been referenced and loaded, and back-patch the original
reference so that a direct pointer to the variable or function can now
be followed for it. Subsequent attempts to access the same
variable/function will hit the already existing entry in the global
lookup table and be resolved much more quickly.
For a *real* understanding of how this works, please see
/usr/src/gnu/usr.bin/ld/rtld/
> If not, how does it deal with global variables being at different places?
Global variables are allocated and initialized at image activiation
time, before much of anything else, and are thus handled a little
differently from function references. I believe that every referenced
shared library is traversed and global storage allocated for the sum
of all global variables allocated by them and the executable. I could
be wrong about this, but that's my essential understanding. :-)
> - Does it support construction of global C++ objects in the library?
> (I.e. is there per-library startup code)
Yes, there's special runtime code linked into C++ programs
(/usr/lib/c++rt0.o as opposed to /usr/lib/crt0.o) which handles this.
> - Does it support libdl? I.e. can new objects be loaded after program started
?
Yes, though the dl*() family of routines are actually stored in the
ld.so, there's no special libdl library you need to link with.
> - How does it do versioning? Is there a concept of major and minor versions?
Yes, both major and minor versions are supported.
> If a program requests a version, what library versions would be offered?
The next older one, if the requested one is not found. A warning
is also generated in this case, just like under SunOS.
> Is the location of the library stored in the image?
Yes, you can compile in the LD_LIBRARY_PATH (-R flag to ld) or you can
simply use the global cache which is managed with ldconfig(1). It's
the programmer's choice, depending on how much flexibility he'd like
the user of his executable to have.
> How does it deal with interdependecies between shared images? I.e. suppose
> I have libfoo.1, libfoo.2 and libbar.1. libbar.1 depends on libfoo.1, and
> libfoo.1 and libfoo.2 are mutually incompatible. Can I build new programs
> so that they get linked with libfoo.2, unless I also need to link with
> libbar.1? If so, do I need to specify this requirement to the linker?
An interesting question - I've never tried this. Why not give it a
shot and get back to me with the answer? :-)
Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19746.849929786>