Revert the folding of .init_array / .fini_array into ___plugin_ctors /
___plugin_dtors. Other ELF-loader backends (3ds, riscos, wii, ds, psp)
keep these as separate sections, and the cross-platform migration to
walk .init_array / .fini_array directly from the loader will be done in
the future (see https://github.com/scummvm/scummvm/pull/7446).
m68k-atari-mintelf-gcc emits .init_array / .fini_array rather than
.ctors / .dtors. I have verified it two ways: scummvm.prg has populated
.init_array (6 entries) and .fini_array (1 entry); and adding a single
namespace-scope `static Foo g;` to an engine TU produces an .init_array
entry in the resulting .plg that lives outside ___plugin_ctors ..
___plugin_ctors_end. So with this layout, such an entry is silently
never run (same of every other ELF backend?). Fortunately, no engine has
such a static today (every built plugin has empty ctor/dtor ranges), so
nothing currently breaks.
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.)
In 2006, Win32PluginProvider was removed from Windows builds:
df5be19409
Instead, SdlPluginProvider became the provider used in Window builds.
Currently, no code uses Win32PluginProvider.
The two classes are small and effectively do the same thing, but
Win32PluginProvider has the advantage of using our Windows string
conversion functions for paths, just like the rest of backend code.
We've seen problems before where SDL handles encoding differently:
0ab9653556
Some toolchains (RiscOS) may not export it in certain conditions.
This list does not enforce the symbol to be here so it shouldn't fail
build on platforms without this symbol.
The new PSP toolchain automatically links system libraries which wasn't
the case before. The ordering of libraries builtin in GCC and our spec
file collided. This fixes the order.
PSP SDK includes time.h so it needs an exemption.
A warning was emitted about a if without curly braces which are needed.
Miro Kropacek
Alexander Reim
Donovan Watteau
Christian Kündig
Le Philousophe
sluicebox
Vladimir Serbinenko
Cameron Cawley
Kaloyan Chehlarski
Francisco Javier Trujillo Mata
Eugene Sandulenko
Orgad Shaneh