summaryrefslogtreecommitdiff
path: root/rts/linker/PEi386.h
Commit message (Collapse)AuthorAgeFilesLines
* rts/linker/PEi386: Add finalization supportBen Gamari2022-07-161-0/+1
| | | | | | This implements #20494 for the PEi386 linker. Happily, this also appears to fix `T9405`, resolving #21361.
* rts/PEi386: Fix handling of weak symbolsBen Gamari2022-05-131-0/+6
| | | | | | | | Previously we would flag the symbol as weak but failed to set its address, which must be computed from an "auxiliary" symbol entry the follows the weak symbol. Fixes #21556.
* rts/PEi386: Move allocateBytes to MMap.cBen Gamari2022-04-061-8/+0
|
* rts/PEi386: Rework linkerBen Gamari2022-04-061-10/+12
| | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | 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.
* Fix a few Note inconsistenciesBen Gamari2022-02-011-1/+1
|
* Windows: Update tarballs to GCC 9.2 and remove MAX_PATH limit.Tamar Christina2019-10-201-1/+0
|
* Allocate bss section within proper range of other sectionsZejun Wu2019-01-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This re-applies {D5195} and {D5235}, they were reverted as part of diff stack to unbreak i386. The proper fix is done in {D5289}. Allocate bss section within proper range of other sections: * when `+RTS -xp` is passed, allocate it contiguously as we did for jump islands * when we mmap the code to lower 2Gb, we should allocate bss section there too Test Plan: 1. `./validate` 2. with ``` DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO ``` `TEST="T15729" make test` passed in both linux (both i386 and x86_64) and macos. 3. Also test in a use case where we used to encouter error like: ``` ghc-iserv-prof: R_X86_64_PC32 relocation out of range: (noname) = b90282ba ``` and now, everything works fine. Reviewers: simonmar, bgamari, angerman, erikd Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15729 Differential Revision: https://phabricator.haskell.org/D5290
* Revert "Batch merge"Ben Gamari2019-01-301-1/+1
| | | | This reverts commit 76c8fd674435a652c75a96c85abbf26f1f221876.
* Batch mergeBen Gamari2019-01-301-1/+1
|
* Revert "Allocate bss section within proper range of other sections"Ben Gamari2018-10-301-1/+1
| | | | | | | | This reverts commit e019ec94f12268dd92ea5d5204e9e57e7ebf10ca. This sadly breaks the external interpreter on i386. For instance, see https://circleci.com/gh/ghc/ghc/10925.
* Allocate bss section within proper range of other sectionsZejun Wu2018-10-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allocate bss section within proper range of other sections: * when `+RTS -xp` is passed, allocate it contiguously as we did for jump islands * when we mmap the code to lower 2Gb, we should allocate bss section there too This depends on {D5195} Test Plan: 1. `./validate` 2. with ``` DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO ``` `TEST="T15729" make test` passed in both linux and macos. 3. Also test in a use case where we used to encouter error like: ``` ghc-iserv-prof: R_X86_64_PC32 relocation out of range: (noname) = b90282ba ``` and now, everything works fine. Reviewers: simonmar, bgamari, angerman, erikd Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15729 Differential Revision: https://phabricator.haskell.org/D5219
* Updated PE linker, section alignment and cleanup.Tamar Christina2018-09-171-7/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is to address a couple of short comings of the PE linker. The first thing it does is properly honor section alignments, so SSE code will work reliably. While doing this I've also changed how it reads and stores ObjectFile information. Previously the entire object file was read in and treated as one blob, including headers, symbol tables etc. Now the ObjectFile is read in but stored in chunks, tables go into a temporary info struct and code/data into a new private heap. This allows me to free all meta data once we're done relocating. Which means we can reclaim this memory. As I've mentioned above I've also moved from using VirtualAlloc to HeapAlloc. The reason is VirtualAlloc is meant to be used for more low level memory allocation, it's very fast because it can only allocate whole blocks, (64k) by default, and the memory must be paged (4k) aligned. So when you ask for e.g. 30k of memory, you're given a whole block where 34k will be wasted memory. Nothing else can ever access that untill you free the 30k. One downside of HeapAlloc is that you're not in control of how the heap grows, and heap memory is always committed. So it's harder to tell how much we're actually using now. Another big upside of splitting off the ObjectCode tables to info structs is that I can adjust them, so that later addressings can just use array subscripts to index into them. This simplifies the code a lot and a lot of complicated casts and indexing can be removed. Leaving less and more simple code. This patch doesn't fix the memprotection but it doesn't regress it either. It does however make the next changes smaller and fixes the alignments. Test Plan: ./validate , new test T13617 Reviewers: bgamari, erikd, simonmar, hvr, angerman Reviewed By: angerman Subscribers: nickkuk, carter, RyanGlScott, rwbarton, thomie GHC Trac Issues: #13617 Differential Revision: https://phabricator.haskell.org/D3915
* Add stack traces on crashes on WindowsTamar Christina2017-10-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds the ability to generate stack traces on crashes for Windows. When running in the interpreter this attempts to use symbol information from the interpreter and information we know about the loaded object files to resolve addresses to symbols. When running compiled it doesn't have this information and then defaults to using symbol information from PDB files. Which for now means only files compiled with ICC or MSVC will show traces compiled. But I have a future patch that may address this shortcoming. Also since I don't know how to walk a pure haskell stack, I can for now only show the last entry. I'm hoping to figure out how Apply.cmm works to be able to walk the stalk and give more entries for pure haskell code. In GHCi ``` $ echo main | inplace/bin/ghc-stage2.exe --interactive ./testsuite/tests/rts/derefnull.hs GHCi, version 8.3.20170830: http://www.haskell.org/ghc/ :? for help Ok, 1 module loaded. Prelude Main> Access violation in generated code when reading 0x0 Attempting to reconstruct a stack trace... Frame Code address * 0x77cde10 0xc370229 E:\..\base\dist-install\build\HSbase-4.10.0.0.o+0x190031 (base_ForeignziStorable_zdfStorableInt4_info+0x3f) ``` and compiled ``` Access violation in generated code when reading 0x0 Attempting to reconstruct a stack trace... Frame Code address * 0xf0dbd0 0x40bb01 E:\..\rts\derefnull.run\derefnull.exe+0xbb01 ``` Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3913
* Big-obj support for the Windows runtime linkerTamar Christina2017-07-081-5/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The normal object file on Windows has a limit of `2^16` sections that can be in an object-file. The `big-obj` format raises this to `2^32` sections. The implementation is made difficult because we now need to support two header formats and two section formats that differ only by a single element size within each. The element that's different is in the middle of the structs and since the structs are used to map regions of memory directly, it means we need to know which struct it is when we do the mapping or pointer arithmetics. This is the final Object-Code format which Windows compilers can generate which we do not support yet in GHCI. All other major compilers on the platforms can produce it and all linkers consume it (bfd and lld). See http://tinyurl.com/bigobj This patch abstracts away retrieving the fields to functions which all take an struct which describes which object format is currently being parsed. These functions are always in-lined as they're small but would looks messy being copy-pasted everywhere. Test Plan: ./validate and new test `big-obj` ``` Tamar@Rage MINGW64 /r $ gcc -c -Wa,-mbig-obj foo.c -o foo.o Tamar@Rage MINGW64 /r $ objdump -h foo.o foo.o: file format pe-bigobj-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000010 0000000000000000 0000000000000000 00000128 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00000000 0000000000000000 0000000000000000 00000000 2**4 ALLOC, LOAD, DATA 2 .bss 00000000 0000000000000000 0000000000000000 00000000 2**4 ALLOC 3 .xdata 00000008 0000000000000000 0000000000000000 00000138 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .pdata 0000000c 0000000000000000 0000000000000000 00000140 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 5 .rdata$zzz 00000030 0000000000000000 0000000000000000 0000014c 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA Tamar@Rage MINGW64 /r $ echo main | ~/ghc/inplace/bin/ghc-stage2.exe --interactive bar.hs foo.o GHCi, version 8.3.20170430: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( bar.hs, interpreted ) Ok, modules loaded: Main. *Main> 17 *Main> Leaving GHCi. ``` Reviewers: austin, bgamari, erikd, simonmar Subscribers: awson, rwbarton, thomie, #ghc_windows_task_force GHC Trac Issues: #13815 Differential Revision: https://phabricator.haskell.org/D3523
* Better import library support for WindowsTamar Christina2017-06-021-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The import library support added for 7.10.3 was only a partial one. This support was predicated on using file extensions to determine whether or not a library was an import library. It also couldn't handle libraries with multiple dll pointers. This is a rewrite of that patch and fully integrating it into the normal archive parsing and loading routines. This solves a host of issues, among others allowing us to finally use `-lgcc_s`. This also fixes a problem with our previous implementation, where we just loaded the DLL and moved on. Doing this had the potential of using the wrong symbol at resolve time. Say a DLL already loaded (A.dll) has symbol a exported (dependency of another dll perhaps). We find an import library `B.lib` explicitly defining an export of `a`. we load `B.dll` but this gets put after `A.dll`, at resolve time we would use the value from `A` instead of `B` which is what we wanted. Test Plan: ./valide and make test TEST=13606 Reviewers: austin, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, RyanGlScott, thomie, #ghc_windows_task_force GHC Trac Issues: #13606, #12499, #12498 Differential Revision: https://phabricator.haskell.org/D3513
* Prefer #if defined to #ifdefBen Gamari2017-04-281-1/+1
| | | | Our new CPP linter enforces this.
* cpp: Use #pragma once instead of #ifndef guardsBen Gamari2017-04-231-4/+1
| | | | | | | | | | | | | | This both says what we mean and silences a bunch of spurious CPP linting warnings. This pragma is supported by all CPP implementations which we support. Reviewers: austin, erikd, simonmar, hvr Reviewed By: simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3482
* Clean up RTS Linker Windows.Tamar Christina2017-01-181-114/+64
| | | | | | | | | | | | | | | | | | | | | | Clean up the linker code for PE. 1. Stop copying structures from the windows header and use those that are in the headers. There's no point in copying them and we got a few types wrong. 2. Replace custom typedef with C99 types. If we're not going to use the Windows type aliases, at least use standard ones. Test Plan: ./validate Reviewers: simonmar, austin, erikd, bgamari Reviewed By: simonmar, bgamari Subscribers: dfeuer, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2944
* linker: Split PEi386 implementation into new source fileBen Gamari2016-11-021-0/+161
Test Plan: Validate Reviewers: erikd, austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2648
View Lorry Controller Status