- Jul 18, 2023
-
-
This is needed to be a correct macOS 10.7 binary.
-
A zerofill section is the only way to reserve address space and prevent system frameworks from using it, including preventing allocations before any preloader code runs: - starting with Ventura, dyld allocates private memory from 0x1000-0x81000. This breaks EXEs that have an image base of 0x10000. - Rosetta allocates memory starting at 0x100000000, which breaks EXEs based there. - starting with Monterey, for proper 10.7 binaries (which include a __program_vars section), libSystem initializes itself before the preloader runs. This fragments the <4GB address space which is needed for Wow64. This will need to be adjusted if any EXEs based at 0x200000000 or higher are found.
-
- Jun 20, 2023
-
-
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: 78ed3438 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55091
-
- Jun 19, 2023
-
-
Alexandre Julliard authored
-
Alexandre Julliard authored
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55050
-
- May 31, 2023
-
-
- Apr 17, 2023
- Mar 29, 2023
-
-
- Mar 27, 2023
- Mar 06, 2023
-
-
-
On Ventura, the Rosetta runtime and dyld shared cache now reach down to 0x7ff7fffb8000 on my system.
-
- Mar 02, 2023
-
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
Alexandre Julliard authored
-
- Feb 13, 2023
-
-
- Feb 08, 2023
-
-
-
The Rutoken driver installer tries to start this service, and fails if it doesn't exist. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54396
-
Now that FLG_ADDREG_APPEND is changed to correctly create the value if it doesn't exist, this is safe, and less error-prone when adding new services.
-
- Feb 01, 2023
-
-
- Jan 24, 2023
-
-
- Dec 07, 2022
-
-
- Dec 05, 2022
-
-
- Dec 01, 2022
- Nov 21, 2022
-
-
- Nov 07, 2022
-
-
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. https://github.com/libunwind/libunwind/commit/4d779f55c0d0a3814453517e54cd0f7bed69ca74 . (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>
-
- Oct 31, 2022
-
-
Commit af996344 used ARRAY_SIZE in FreeBSD-specifc code which, alas, is not available here, so revert that change.
-
- Oct 25, 2022
-
-
- Jul 19, 2022
-
-
Signed-off-by:
Paul Gofman <pgofman@codeweavers.com>
-
- Jul 04, 2022
-
-
This is required for fetching pointer-valued vectors (e.g. AT_SYSINFO_EHDR). Signed-off-by:
Jinoh Kang <jinoh.kang.kr@gmail.com>
-
- Jun 24, 2022
-
-
Alexandre Julliard authored
Based on a script written by Giovanni Mascellani. Signed-off-by:
Alexandre Julliard <julliard@winehq.org>
-
- Apr 28, 2022
-
-
New time zone data were generated from CLDR release 41 and tzdata release 2022a. Signed-off-by:
Giovanni Mascellani <gmascellani@codeweavers.com> Signed-off-by:
Alexandre Julliard <julliard@winehq.org>
-
- Mar 24, 2022
-
-
Alexandre Julliard authored
Signed-off-by:
Alexandre Julliard <julliard@winehq.org>
-
- Mar 21, 2022
-
-
Alexandre Julliard authored
Signed-off-by:
Alexandre Julliard <julliard@winehq.org>
-
- Mar 18, 2022
-
-
Alexandre Julliard authored
Signed-off-by:
Alexandre Julliard <julliard@winehq.org>
-
Alexandre Julliard authored
Signed-off-by:
Alexandre Julliard <julliard@winehq.org>
-
- Mar 02, 2022
-
-
Signed-off-by:
Zhiyi Zhang <zzhang@codeweavers.com> Signed-off-by:
Alexandre Julliard <julliard@winehq.org>
-