Atari's mintelf platform has ELF support but its libc does not provide
__cxa_atexit / __cxa_finalize, so -fuse-cxa-atexit cannot be used out of
the box. Add a minimal shim (plus a __dso_handle definition for the main
executable) so plugins can register and finalize their function-local
static destructors per DSO on unload.
Note: earlier version ran __cxa_finalize from the host via
findSymbol("__dso_handle"). That works as long as exactly one
__dso_handle ends up in the plugin's symtab (the plugin's own).
When the main binary also defines __dso_handle (so the host's
function-local statics can link with -fuse-cxa-atexit), it breaks: the
plugin link uses --just-symbols=<main binary> and imports that as a
second __dso_handle, and findSymbol can then return the host-imported
one instead of the plugin's own. The two addresses differ, so
__cxa_finalize matches nothing.
The plugin-side helper avoids the ambiguity on every target by using
whichever __dso_handle the plugin's own code already resolved against --
the same one embedded in its __cxa_atexit calls. (PSP2's plugin runtime
has always called __cxa_finalize from inside the plugin for the same
reason; see backends/plugins/psp2/plugin.cpp.)
This is a degradation from the split of detection plugins. All the
caching code which was present was left with detection plugins which
now make no sense: we always load all detection plugins as a whole.
This commit moves the caching logic over to the Engine plugins.
This opens a question now whether we should move all to UNCACHED_PLUGINS
- MetaEngines will now always go to the executable.
- But, because they still live in engine projects and are connected via a macro, they will need to be differentiated from Engines.
- This macro, and it's use in future will help in that.
The engine ID identifies which engine should be used to launch the target.
Also remove the 'single ID' system. Different games from engines that used
that system now have different game IDs.
Also-By: Matthew Hoops <clone2727@gmail.com>
Previously, a C-style cast was used to convert a
Common::Array<Plugin *>, populated with pointers to StaticPlugin
and DynamicPlugin instances, to a
Common::Array<PluginSubclass<T> *>, but PluginSubclass<T> is a
*sibling* class to StaticPlugin/DynamicPlugin, so this cast was
invalid and the results undefined. The methods for retrieving
subclasses of plugins can't be easily changed to just generate an
array of temporary wrapper objects that expose an identical API
which dereferences to the preferred PluginObject subclass because
pointers to these objects are retained by other parts of ScummVM,
so the wrappers would needed to be persisted or they would need to
just re-expose the underlying Plugin object again. This indicated
that a way to solve this problem is to have the callers receive
Plugin objects and get the PluginObject from the Plugin by
explicitly stating their desired type, in a similar manner to
std::get(std::variant), so that the pattern used by this patch to
solve the problem.
Closes gh-1051.
This tries to make our code a bit more compliant with our code formatting
conventions. For future use, this is the command I used:
git ls-files "*.cpp" "*.h" | xargs sed -i -e 's/[ \t]*$//'
After searching for the right plugin once, the filename will be saved to the config file under the domain 'plugin_files'. The key is the gameid and the value is the plugin file. The backup mechanism is searching plugin by plugin.
svn-id: r55061
The reason for this was that I found issues where the wrong functions were called in EngineManager for single plugin operation. Rather than inserting more messy #defines, I preferred to change the PluginManager to use virtual functions, which also makes EngineManager simpler.
svn-id: r55024
I reduced memory fragmentation using 2 principles: Plugins should be loaded for as little time as possible, and long lasting memory allocations should be allocated before plugins are loaded. There might still be a little fragmentation left.
Note that command line settings that require plugins to be loaded don't work yet, but they didn't work (properly) before either.
svn-id: r54097
The ELF loader does not have access to the symbols of the main
executable, it just relocates symbols to it via fixed offsets. We need
to make sure that loaded plugins are from the same link process to
prevent crashes. An embedded build date is used for that.
svn-id: r52730