we recently ran into some nasty backwards/forwards compatibility problems
between ast executables and link-time-dlls and plugin-dlls
first some background on ast plugins
plugins are divided into domains
plugin domains are named by the main executable or library for the domain
ast currently has these plugin domains
codex open/read/write/close data transform methods
dss data stream scan { types schemas queries }
ksh ksh builtins
pax archive formats
pz pzip methods
sort sort methods
vcodex buffer=>buffer data transform methods
each plugin domain has one or more dll/so files that contain the plugins
each dll/so file contains one or more plugins
for plugins the main problems are:
(a) new executable old plugin
(b) old executable new plugin
to solve the problem each plugin domain has a current YYYYMMDD version stamp
this stamp is defined as a macro in the domain plugin header (e.g., shcmd.h for
ksh)
the plugin version stamp is compiled into both the executable and plugins
executables load plugins by the ast -ldll function dllplugin()
which takes the plugin domain version stamp as an argument
dllplugin() does a PATH relative search to find the plugin dll/so
only plugin dlls/sos with version stamp >= the caller version stamp are accepted
the search continues until a suitable version stamp is hit or none are found
each plugin dll/so must have a function
unsigned long plugin_version(void)
that returns the plugin version stamp for all of the plugins it contains
each domain plugin header has a macro that encodes this function
for ksh its
SHLIB(ksh)
(the ksh is currently ignored) which expands to
unsigned long plugin_version(void) { return SH_PLUGIN_VERSION; }
we modified our plugin builds to have a file lib.c that contains
the plugin_version() definition
now the plugin-version >= caller-version test only works if the plugins
are coded to preserve backwards compatibility -- ast pretty much over
the years has retained backwards compatibility, but with the last release
we put build/coding mechanisms in place to solidify backward compatibility
-- more on that in a future note
we burned an afternoon discussing backwards compatibility implementations
an alternative for plugin version stamps would be to put the version in
the plugin dll/so name -- we concluded this would have led to a pile
of bit-rotting plugin dll/so files that would be hard to maintain and
garbage collect -- with backwards compatibility properly implemented
it will be safe to replace plugin dll/so files with the latest release
and still maintain compatibility with old executables that use the plugins
a note on ast section 3 documentation: one of my goals for the remainder of
the summer is to document all of the ast library public functions
I'll start with dll(3)
> > On Sun, Aug 1, 2010 at 4:37 AM, Finnbarr Murphy <[email protected]> wrote:
> > > Plugins appear to have stopped working in the latest release of ksh93
> > > - at least on 64-bit Linux.
> > >
> > > Here is a very simple crude "HelloWorld" example of a plugin:
> > > #include <stdio.h>
> > > int
> > > b_hello(int argc, char *argv[], void *extra)
> > > {
> > > if (argc != 2) {
> > > fprintf(stderr,"Usage: hello arg\n");
> > > return(2);
> > > }
> > > printf("Hello %s\n", argv[1]);
> > > return(0);
> > > }
> > > which is built as follows:
> > > gcc -fPIC -g -c hello.c
> > > gcc -shared -W1,-soname,libhello.so -o libhello.so hello.o
> > > Works fine on ksh83 Version JM 93t+ 2010-03-05 and earlier
> > > $ ./ksh
> > > $ echo ${.sh.version}
> > > Version JM 93t+ 2010-03-05
> > > $ builtin -f ./libhello.so hello
> > > $ hello world
> > > Hello there world
> > > $
> > > but core dumps on later versions of ksh93
> > > $ /bin/ksh
> > > $ echo ${.sh.version}
> > > Version JM 93t+ 2010-06-21
> > > $ builtin -f ./libhello.so hello
> > > Memory fault(coredump)
> > > Program terminated with signal 11, Segmentation fault.
> > > #0 dllplugin (lib=0x0, name=0x177c531 "./libhello.so",
> > > ver=<value optimized out>, rel=20100528, flags=1, path=0x0, size=0)
> > > at /usr/src/debug/ksh-20100621/src/lib/libdll/dllplug.c:82
> > > 82 if (!dllcheck(dll, dle->path, rel))
> > > Extensive work was recently done in libdll. New source code
> > > files include dlllib.h, dllcheck.c, dllerror.c, dllplug.c.
> > > Is there now a requirement to have a version number on a plugin?
> > > Do plugins need to be build differently?
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
