Skip to content
Snippets Groups Projects
  1. Jul 18, 2023
    • Brendan Shanks's avatar
      loader: In macOS preloader, add __program_vars section. · 4e6dbf3b
      Brendan Shanks authored and Alexandre Julliard's avatar Alexandre Julliard committed
      This is needed to be a correct macOS 10.7 binary.
      4e6dbf3b
    • Brendan Shanks's avatar
      loader: On 64-bit macOS, reserve the low 8GB using a zerofill section. · cfa0dd9d
      Brendan Shanks authored and Alexandre Julliard's avatar Alexandre Julliard committed
      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.
      cfa0dd9d
  2. Jun 20, 2023
    • Jinoh Kang's avatar
      loader: Set the visibility of symbols in preloader to "hidden". · 966233ae
      Jinoh Kang authored and Alexandre Julliard's avatar Alexandre Julliard committed
      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
      966233ae
  3. Jun 19, 2023
  4. May 31, 2023
  5. Apr 17, 2023
  6. Mar 29, 2023
  7. Mar 27, 2023
  8. Mar 06, 2023
  9. Mar 02, 2023
  10. Feb 13, 2023
  11. Feb 08, 2023
  12. Feb 01, 2023
  13. Jan 24, 2023
  14. Dec 07, 2022
  15. Dec 05, 2022
  16. Dec 01, 2022
  17. Nov 21, 2022
  18. Nov 07, 2022
    • Martin Storsjö's avatar
      ntdll: Add ARM EHABI unwind instructions in assembly functions. · f7609768
      Martin Storsjö authored and Alexandre Julliard's avatar Alexandre Julliard committed
      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: default avatarMartin Storsjö <martin@martin.st>
      f7609768
  19. Oct 31, 2022
  20. Oct 25, 2022
  21. Jul 19, 2022
  22. Jul 04, 2022
  23. Jun 24, 2022
  24. Apr 28, 2022
  25. Mar 24, 2022
  26. Mar 21, 2022
  27. Mar 18, 2022
  28. Mar 02, 2022
Loading