On Fri, Apr 23, 2010 at 05:25:50PM +0200, I. Szczesniak wrote: > AFAIK I can bring some light into the story.
Thank you, this is very useful information. > Interposition has some serious side effects: > 1. Interposition only works reliable for executables but *NOT* for > shared libraries. It can't be used if we want to use AST stdio or sfio > in libperl, libfreetype2 or X11. The implementation in ON allows that > a single application or shared library can mix different types of > stdio and other function packages without trouble. Not quite. If the library is linked into the executable, then the library's interposers will work globally for that program. However, in any other case, you're right, the library's interposers will not work. E.g., if the library is brought in at run-time via dlopen() without having been known to the link-editor when the program was linked (as opposed to brought in late because of lazy loading). > 2. Interposition is very slow. I helped Roland looking at the time > needed to load the libraries and reducing the overhead of loading > them. Using interposition destroys this advantage and affects the > start up time of every application which uses libast. I'll ask the linker folks about this. > 3. Interposition requires that the ABI of shared libraries must match > 100% the API it replaces. This would be a disaster in many cases like Yes, this is true, and if AST's replacements don't, then you're quite right that you cannot use interposition. > stdio because the change in ABI is actually what fixed so many > problems, i.e. stdio, regex, fnmatch, ... are all great examples where > the Solaris API is broken beyond repair. Unfortunately Sun was never > willing to fix those problems and added kludges on top of the existing > problems instead. The actual *bold* step of replacing the > implementation (and keep the old available via ELF version) was sadly > never done. We couldn't break the stdio ABI without breaking backwards compatibility. We care about binary backwards compatibility, so we didn't break the stdio ABI. We have constraints that AST doesn't have. What (1) and (3) amount to is this: AST cannot be used freely, but only by programs specifically intended to use AST. The symbol renaming approach has similar drawbacks, but is less constraining: you just need to make sure that never the twain (libc and libast) shall meet, and should assume that both will be in use concurrently in the same process (particularly if libast is a dependency of an object that could be brought in at run-time via dlopen()). Thanks, Nico -- _______________________________________________ ksh93-integration-discuss mailing list ksh93-integration-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
