summaryrefslogtreecommitdiff
path: root/rts/Linker.c
Commit message (Collapse)AuthorAgeFilesLines
* linker: Fix BFD import librariesTamar Christina2023-02-031-12/+14
| | | | | | | | | | This commit fixes the BFD style import library support in the runtime linker. This was accidentally broken during the refactoring to clang and went unnoticed because clang itself is unable to generate the BFD style import libraries. With this change we can not link against both GCC or Clang produced libraries again and intermix code produced by both compilers.
* Windows: Remove mingwex dependencyRyan Scott2023-02-031-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The clang based toolchain uses ucrt as its math library and so mingwex is no longer needed. In fact using mingwex will cause incompatibilities as the default routines in both have differing ULPs and string formatting modifiers. ``` $ LIBRARY_PATH=/mingw64/lib ghc/_build/stage1/bin/ghc Bug.hs -fforce-recomp && ./Bug.exe [1 of 2] Compiling Main ( Bug.hs, Bug.o ) ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `__imp___p__environ' ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `__hscore_get_errno' ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_ForeignziCziError_errnoToIOError_info' ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziWindows_failIf2_closure' ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziEncodingziCodePageziAPI_mkCodePageEncoding_info' ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziEncodingziCodePage_currentCodePage_closure' ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziEncoding_getForeignEncoding_closure' ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_ForeignziCziString_withCStringLen1_info' ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziHandleziInternals_zdwflushCharReadBuffer_info' ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziIOziHandleziText_hGetBuf1_info' ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziFingerprint_fingerprintString_closure' ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_DataziTypeableziInternal_mkTrCon_closure' ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziException_errorCallWithCallStackException_closure' ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\base-4.17.0.0\libHSbase-4.17.0.0.a: unknown symbol `base_GHCziErr_error_info' ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\template-haskell-2.19.0.0\libHStemplate-haskell-2.19.0.0.a: unknown symbol `base_DataziMaybe_fromJust1_info' ghc.exe: | C:\Users\winferno\Software\ghc\_build\stage1\lib\x86_64-windows-ghc-9.5.20220908\template-haskell-2.19.0.0\libHStemplate-haskell-2.19.0.0.a: unknown symbol `templatezmhaskell_LanguageziHaskellziTHziSyntax_IntPrimL_con_info' ghc.exe: ^^ Could not load 'templatezmhaskell_LanguageziHaskellziTHziLibziInternal_stringL_closure', dependency unresolved. See top entry above. <no location info>: error: GHC.ByteCode.Linker.lookupCE During interactive linking, GHCi couldn't find the following symbol: templatezmhaskell_LanguageziHaskellziTHziLibziInternal_stringL_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please report this as a GHC bug: https://www.haskell.org/ghc/reportabug ```
* rts: wasm32 placeholder linkerCheng Shao2022-11-111-0/+2
| | | | | | This patch adds minimal placeholder linker logic for wasm32, just enough to unblock compiling rts on wasm32. RTS linker functionality is not properly implemented yet for wasm32.
* rts: don't define RTS_USER_SIGNALS when signal.h is not presentCheng Shao2022-11-111-1/+1
| | | | | | | | In the rts, we have a RTS_USER_SIGNALS macro, and most signal-related logic is guarded with RTS_USER_SIGNALS. This patch extends the range of code guarded with RTS_USER_SIGNALS, and define RTS_USER_SIGNALS iff signal.h is actually detected by autoconf. This is required for wasm32-wasi to work, which lacks signals.
* rts: introduce (and use) `STG_NORETURN`Nicolas Trangez2022-11-021-1/+1
| | | | | | | Instead of sprinkling the codebase with `GNU(C3)_ATTRIBUTE(__noreturn__)`, add a `STG_NORETURN` macro (for, basically, the same thing) similar to `STG_UNUSED` and others, and update the code to use this macro where applicable.
* rts/linker: Resolve iconv_* on FreeBSDBen Gamari2022-08-091-9/+50
| | | | | | | | | | FreeBSD's libiconv includes an implementation of the iconv_* functions in libc. Unfortunately these can only be resolved using dlvsym, which is how the RTS linker usually resolves such functions. To fix this we include an ad-hoc special case for iconv_*. Fixes #20354.
* rts/linker: Ensure that __cxa_finalize is called on code unloadBen Gamari2022-07-161-0/+18
|
* rts/linker: Fix resolution of __dso_handle on DarwinBen Gamari2022-07-161-1/+1
| | | | Darwin expects a leading underscore.
* rts/linker/MachO: Introduce finalizer supportBen Gamari2022-07-161-0/+2
|
* rts/linker/PEi386: Add finalization supportBen Gamari2022-07-161-0/+2
| | | | | | This implements #20494 for the PEi386 linker. Happily, this also appears to fix `T9405`, resolving #21361.
* rts/linker/Elf: Introduce support for invoking finalizers on unloadBen Gamari2022-07-161-0/+10
| | | | Addresses #20494.
* rts: Add debug output on ocResolve failureBen Gamari2022-05-131-1/+4
| | | | This makes it easier to see how resolution failures nest.
* rts/linker: Split up object resolution and initializationBen Gamari2022-04-061-15/+60
| | | | | | | | | | | | | | | | | | | | | | | | | Previously the RTS linker would call initializers during the "resolve" phase of linking. However, this is problematic in the case of cyclic dependencies between objects. In particular, consider the case where we have a situation where a static library contains a set of recursive objects: * object A has depends upon symbols in object B * object B has an initializer that depends upon object A * we try to load object A The linker would previously: 1. start resolving object A 2. encounter the reference to object B, loading it resolve object B 3. run object B's initializer 4. the initializer will attempt to call into object A, which hasn't been fully resolved (and therefore protected) Fix this by moving constructor execution to a new linking phase, which follows resolution. Fix #21253.
* rts/linker: More descriptive debug outputBen Gamari2022-04-061-12/+15
|
* rts/PEi386: Rework linkerBen Gamari2022-04-061-12/+4
| | | | | | | | | | | | | | | | This is a significant rework of the PEi386 linker, making the linker compatible with high image base addresses. Specifically, we now use the m32 allocator instead of `HeapAllocate`. In addition I found a number of latent bugs in our handling of import libraries and relocations. I've added quite a few comments describing what I've learned about Windows import libraries while fixing these. Thanks to Tamar Christina (@Phyx) for providing the address space search logic, countless hours of help while debugging, and his boundless Windows knowledge. Co-Authored-By: Tamar Christina <tamar@zhox.com>
* rts/linker: Preserve information about symbol typesBen Gamari2022-04-061-9/+50
| | | | | | | | | | | | | As noted in #20978, the linker would previously handle overflowed relocations by creating a jump island. While this is fine in the case of code symbols, it's very much not okay in the case of data symbols. To fix this we must keep track of whether each symbol is code or data and relocate them appropriately. This patch takes the first step in this direction, adding a symbol type field to the linker's symbol table. It doesn't yet change relocation behavior to take advantage of this knowledge. Fixes #20978.
* Add a Note describing lack of object merging on WindowsBen Gamari2022-04-061-0/+2
| | | | See #21068.
* rts/linker: Catch archives masquerading as object filesBen Gamari2022-04-061-1/+10
| | | | | | | Check the file's header to catch static archive bearing the `.o` extension, as may happen on Windows after the Clang refactoring. See #21068
* rts/linker/MMap: Use MemoryAccess in mmapForLinkerBen Gamari2022-02-091-3/+2
|
* rts: Move mmapForLinker and friends to linker/MMap.cBen Gamari2022-02-091-251/+1
| | | | They are not particularly related to linking.
* rts: Rename MemoryMap.[ch] -> ReportMemoryMap.[ch]Ben Gamari2022-02-091-1/+1
|
* rts: Dump memory map on memory mapping failuresBen Gamari2022-02-061-0/+3
| | | | Fixes #20992.
* rts: Generalize mmapForLinkerMarkExecutableGHC GitLab CI2022-02-061-10/+46
| | | | | Renamed to mprotectForLinker and allowed setting of arbitrary protection modes.
* rts/m32: Accept any address within 4GB of program textBen Gamari2022-02-061-56/+1
| | | | | | | | | | | Previously m32 would assume that the program image was located near the start of the address space and therefore assume that it wanted pages in the bottom 4GB of address space. Instead we now check whether they are within 4GB of whereever the program is loaded. This is necessary on Windows, which now tends to place the image in high memory. The eventual goal is to use m32 to allocate memory for linker sections on Windows.
* Fix a few Note inconsistenciesBen Gamari2022-02-011-4/+5
|
* Use PATH_FMT instead of %s to format `pathchar *`Ben Gamari2022-01-301-2/+2
| | | | A few %s occurrences have snuck in over the past months.
* Respect W^X in Linker.c:preloadObjectFile on OpenBSDGreg Steuck2021-12-121-1/+1
| | | | This fixes -fexternal-interpreter for ghci. Fixes #20814.
* rts/Linker: Ensure that mmap_32bit_base is updated after mappingBen Gamari2021-12-071-21/+22
| | | | | | | | | | The amount of duplicated code in `mmapForLinker` hid the fact that some codepaths would fail to update `mmap_32bit_base` (specifically, on platforms like OpenBSD where `MAP_32BIT` is not supported). Refactor the function to make the implementation more obviously correct. Closes #20734.
* linker: Introduce linker_verbose debug outputBen Gamari2021-11-291-16/+19
| | | | | | | | This splits the -Dl RTS debug output into two distinct flags: * `+RTS -Dl` shows errors and debug output which scales with at most O(# objects) * `+RTS -DL` shows debug output which scales with O(# symbols)t
* mmapForLinkerMarkExecutable: do nothing when len = 0Travis Whitaker2021-11-121-0/+6
|
* rts/linker: Introduce a notion of strong symbolsBen Gamari2021-10-121-13/+22
|
* rts/linker: Resolve __fini_array_* symbols to NULLGHC GitLab CI2021-10-121-0/+4
| | | | | If the __fini_array_{start,end} symbols are not defined (e.g. as is often the case when linking against musl) then resolve them to NULL.
* rts/linker: Define _DYNAMIC when necessaryBen Gamari2021-10-121-1/+13
| | | | | | Usually the dynamic linker would define _DYNAMIC. However, when dynamic linking is not supported (e.g. on musl) it is safe to define it to be NULL.
* rts/Linker: Fix __dso_handle handlingGHC GitLab CI2021-10-121-10/+27
| | | | | | | | | | | | Previously the linker's handling of __dso_handle was quite wrong. Not only did we claim that __dso_handle could be NULL when statically linking (which it can not), we didn't even implement this mislead theory faithfully and instead resolved the symbol to a random pointer. This lead to the failing relocations on AArch64 noted in #20493. Here we try to implement __dso_handle as a dynamic linker would do, choosing an address within the loaded object (specifically its start address) to serve as the object's handle.
* Make `PosixSource.h` installed and under `rts/`John Ericson2021-08-091-1/+1
| | | | | | is used outside of the rts so we do this rather than just fish it out of the repo in ad-hoc way, in order to make packages in this repo more self-contained.
* Allocate Adjustors and mark them readable in two stepsMoritz Angermann2021-03-291-1/+1
| | | | | | | | | This drops allocateExec for darwin, and replaces it with a alloc, write, mark executable strategy instead. This prevents us from trying to allocate an executable range and then write to it, which X^W will prohibit on darwin. This will *only* work if we can use mmap.
* linker: Fix atexit handlers on PETamar Christina2021-02-221-3/+0
|
* rts/linker: Don't assume existence of dlinfoBen Gamari2021-01-171-1/+0
| | | | | | | | | The native-code codepath uses dlinfo to identify memory regions owned by a loaded dynamic object, facilitating safe unload. Unfortunately, this interface is not always available. Add an autoconf check for it and introduce a safe fallback behavior. Fixes #19159.
* rts/Linker: Add noreturn to loadNativeObj on non-ELF platformsBen Gamari2021-01-071-2/+6
|
* rts/linker: Use m32 to allocate symbol extras in PEi386Ben Gamari2020-12-011-2/+3
|
* rts/m32: Introduce NEEDS_M32 macroBen Gamari2020-12-011-4/+6
| | | | Instead of relying on RTS_LINKER_USE_MMAP
* rts/Linker: Introduce Windows implementations for mmapForLinker, et al.Ben Gamari2020-12-011-1/+32
|
* rts/linker: Introduce munmapForLinkerBen Gamari2020-12-011-4/+14
| | | | Consolidates munmap calls to ensure consistent error handling.
* rts: Introduce mmapAnonForLinkerBen Gamari2020-12-011-1/+11
| | | | | | | | Previously most of the uses of mmapForLinker were mapping anonymous memory, resulting in a great deal of unnecessary repetition. Factor this out into a new helper. Also fixes a few places where error checking was missing or suboptimal.
* rts/linker: Move shared library loading logic into Elf.cBen Gamari2020-11-301-140/+2
|
* rts/linker: Initialise CCSs from native shared objectsBen Gamari2020-11-301-0/+6
|
* rts/linker: Don't allow shared libraries to be loaded multiple timesBen Gamari2020-11-301-0/+9
|
* rts/linker: Replace some ASSERTs with CHECKBen Gamari2020-11-301-5/+3
| | | | | | | | In the past some people have confused ASSERT, which is for checking internal invariants, which CHECK, which should be used when checking things that might fail due to bad input (and therefore should be enabled even in the release compiler). Change some of these cases in the linker to use CHECK.
* Add loadNativeObj and unloadNativeObjRay Shih2020-11-111-2/+194
| | | | | | | | | | | | | | | | | | | (This change is originally written by niteria) This adds two functions: * `loadNativeObj` * `unloadNativeObj` and implements them for Linux. They are useful if you want to load a shared object with Haskell code using the system linker and have GHC call dlclose() after the code is no longer referenced from the heap. Using the system linker allows you to load the shared object above outside the low-mem region. It also loads the DWARF sections in a way that `perf` understands. `dl_iterate_phdr` is what makes this implementation Linux specific.
* Fix and enable object unloading in GHCiÖmer Sinan Ağacan2020-11-111-79/+61
| | | | | | | Fixes #16525 by tracking dependencies between object file symbols and marking symbol liveness during garbage collection See Note [Object unloading] in CheckUnload.c for details.
View Lorry Controller Status