Linked by Thom Holwerda on Wed 9th Nov 2011 21:26 UTC, submitted by edwin
General Unix Way back in 2002, MIT decided it needed to start teaching a course in operating system engineering. As part of this course, students would write an exokernel on x86, using Sixth Edition Unix (V6) and John Lions' commentary as course material. This, however, posed problems.
Thread beginning with comment 496957
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: binary for windows....
by Vanders on Fri 11th Nov 2011 12:48 UTC in reply to "RE[2]: binary for windows.... "
Vanders
Member since:
2005-07-06

Shared libraries are the cause of all dependency problems


Library versioning and symbol versioning are a solved problem. It's only when developers do not follow the standards that they introduce problems. In a properly managed library dependency issues are non-existent. Glibc is the obvious example here: since Glibc2 (libc.so.6) was introduced on Linux, the library has remained both forwards and backwards compatible.

Consider, that shared libraries can't be optimized over API calls. It might take 30 bytes to call a libc function, which shifts the bytes around again to do a syscall. In a static application, it could theoretically optimize away all the glue code to do a syscall directly while saving space.


The glue code is either needed, or it is not needed. If it's needed, then you can't simply "optimize it away". If it's not needed, then you can just remove it from the syscall shim.

Remember that in many cases the syscall shim will also attempt to avoid a syscall. It's much, much better to do the sanity checking and return early if the arguments are bad before making the syscall. It may require a few more instructions before the syscall happens, but that's still far less expensive than making the syscall only for it to return immediately because the arguments are wrong.

In some cases it's also entirely possible for the syscall shim to satisfy the caller entirely from user space I.e. it doesn't even need to call into the kernel.

Obviously we have to look at bigger libraries too, like libjpg, but even there I wonder how much space would be wasted if it were statically compiled.

This isn't to preclude to the use of shared libraries for applications which are genuinely related and deployed together. But I do see an awful lot of application specific libraries under /lib which have to be managed in lockstep with their associated application, why should these be shared libraries at all?


Now this is where I do a 180 and agree with you! Shared libraries are overused and in a large percentage of cases are used inappropriately. As a simple rule of thumb I'd prefer that system libraries are shared, and any third party libraries required by an application should be static. That's not fool proof, but it's a starting point.

Reply Parent Score: 3

Alfman Member since:
2011-01-28

Vanders,

"The glue code is either needed, or it is not needed. If it's needed, then you can't simply "optimize it away". If it's not needed, then you can just remove it from the syscall shim."


I agree with most of your post, but the problem with shared libraries is that often times they just add a layer of indirection to the syscall without adding much value. If you use a shared library to perform a function, then you cannot optimize away the glue code used to call the shared library.

On the other hand if we're willing to internalize the code into a static binary, the glue code becomes unnecessary (I'm not sure that GCC/LD will do this kind of optimization, but the potential is certainly there).

Reply Parent Score: 2

Vanders Member since:
2005-07-06

If you use a shared library to perform a function, then you cannot optimize away the glue code used to call the shared library.


That's not how shared libraries work. There is no more code required (at run time) to call a function in a shared library than there is in calling a function within the executable.

Reply Parent Score: 2