Today, the preloader is linked with -fPIE in spite of the fact that the
preloader is a non-PIE statically linked binary. This is due to a
limitation in tools/makedep that makes it difficult to specify CFLAGS
for each individual object file's recipe.
This can seemingly cause problems with some GOTPCREL(X) relocations
inside the preloader. Since preloader does not link to the system
library directly, there is no need for a Global Offset Table (GOT).
However, a few extern (non-static) function symbols are declared, the
use of which makes GCC emit instructions that references those symbols
by indirection through GOT. The linker then tries to optimize such
instructions to eliminate GOT references, which can fail due to various
reasons.
This stands in contradiction with Jinoh Kang's suggestion (in bug 55050)
that "-fPIE is harmless even when applied to an object linked into
non-PIE executables." The claim is theoretically true since
position-independent code can in principle be relocated to any address
(fixed or dynamic); however, it fails due to some peculiar practical
issues, which is arguably a limitation in the linker's implementation
(since it can be worked around with -Wl,--no-relax without issues).
Fix this by eliminating GOT usage by setting the default visibility of
non-static declarations to "hidden". Assuming GCC's medium code model
(-mcmodel=medium; default code model for x86_64), this suppresses any
unnecessary PLT or GOT relocations for defined symbols, and provides
opportunity for GCC to optimize the code better.
Fixes: 78ed343842
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55091
On most ELF platforms on ARM, ARM EHABI is the unwind info
format normally used, instead of DWARF like on most other platforms.
Currently, when unwinding through ELF objects with libunwind, the
libraries don't have any .eh_frame section mapped at runtime (since
DWARF isn't used for unwinding). Instead, what happens is that
libunwind ends up loading .debug_frame from the libraries on disk
instead.
Therefore, currently, ELF unwinding relies on the .so files not being
stripped.
This patch adds the necessary EHABI unwinding instructions in the
assembly functions that currently have DWARF CFI instructions.
EHABI isn't signaled via any specific preprocessor macro, but
is signaled by the absence of other unwind mechanisms (such
as __ARM_DWARF_EH__ and __SEH__, or maybe SjLj).
Mark the asm functions in the preloaders as .cantunwind, to avoid
undefined references to __aeabi_unwind_cpp_pr* functions.
Also mark other assembly functions as .cantunwind; for
signal_exit_thread this is essential if the function is marked
with .fnstart/.fnend - otherwise exiting threads does hang.
(pthread_exit internally calls _Unwind_ForcedUnwind, which would
hang if signal_exit_thread had .fnstart without any matching unwind
info).
This would, in principle, allow unwinding through these functions with
libunwind, for versions of libunwind that can parse the EHABI unwind
info - see e.g.
4d779f55c0.
(This commit isn't yet in any current release AFAIK). Unwinding with
EHABI via libunwind would require a few tweaks to the libunwind interface
usage in unix/signal_arm.c though, since e.g. the unw_get_proc_info call
fails if there's no .eh_frame or .debug_frame available.
Signed-off-by: Martin Storsjö <martin@martin.st>
Since 28fe84da45, the main exe image
must be mappable at its desired base address, which essentially
requires the preloader.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51539
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
