Bochs/bochs-testing/plugin-test/test5-execsymbols
2002-10-12 05:52:55 +00:00
..
Makefile.in - support VPATH build 2002-10-11 18:32:27 +00:00
module1.cc - test5-execsymbols checks that a module can reach symbols that are defined in 2002-10-11 16:45:31 +00:00
module1.h - test5-execsymbols checks that a module can reach symbols that are defined in 2002-10-11 16:45:31 +00:00
module2.cc - test5-execsymbols checks that a module can reach symbols that are defined in 2002-10-11 16:45:31 +00:00
module2.h - test5-execsymbols checks that a module can reach symbols that are defined in 2002-10-11 16:45:31 +00:00
README - add some test results and comments 2002-10-12 05:52:55 +00:00
uselib.cc - test5-execsymbols checks that a module can reach symbols that are defined in 2002-10-11 16:45:31 +00:00
uselib.h - test5-execsymbols checks that a module can reach symbols that are defined in 2002-10-11 16:45:31 +00:00

test5-execsymbols

Can a module reference symbols in the executable?

module1 exports module_name and operate(int,int).
module2 exports n_operations and operation_occurred().

uselib.cc uses symbols and functions from both modules.
Module1 calls operation_occurred() in module2.

Module2 calls register_module() in uselib.cc the first time
it is called.

Results:
redhat linux: works fine.
solaris: works fine.
macosX: works fine.
cygwin: 
  when building a DLL you cannot have undefined symbols at link time.
  You have to put -no-undefined on the command line, but whether you
  do or not, you get undefined symbol register_module when you try to
  link module2.

    test5-execsymbols/module2.cc:11: undefined reference to `register_module(char const *)'

DLLs don't allow any symbols to be undefined at link time.  So you have to
choose the order of how to build things so that each link is complete.
For a DLL that's used as a shared library, it must be built and linked on
its own (without the program), with symbols exported.  This link must be
complete, so it can't depend on pieces from the program.  Then, the 
program can be linked with the DLL, with the program reading symbols from
the DLL.  It can't go both ways.

For a plugin environment, we want the plugin to be able to call functions
in the main code, without putting every single thing as a function pointer.
So the main executable should be built first, with appropriate symbols 
exported, and then the plugin can import those symbols.  The main 
executable will find symbols in the DLL using lt_dlopen() and lt_dlsym(),
which probably maps to LoadLibrary() and GetProcAddress().

I will try this in test 6!