#9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows ---------------------------------+----------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by kdmadej): I've encountered a similar error while working on windows myself. Checked with the attached example and it also crashes. Is there a chance this matter will get looked into? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9907#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: GHCi crash | (amd64) Blocked By: | Test Case: Related Tickets: #7103, #10051 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by danilo2): Replying to [comment:2 rwbarton]: Hello rwbarton! I'm working with both kdmadej as well as mmikolajczyk and this bug is some kind of blocker for us. I would love to ask you if can we discuss possible solutions / workarounds to make our use case work? We would like to collaborate with you guys as strong as we are able, we can try to investigate it further if you provide any hints for us - anything. As a side-note: we are using GHCi (or more strictly GHC API) under the hood and GHCi is some kind of interpreter our product bases on - because of that and because the release deadline is in very narrow time from now, we are worrying about that issue. I would be very thankful for any help! :) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9907#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: GHCi crash | (amd64) Blocked By: | Test Case: Related Tickets: #7103, #10051 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by danilo2): Replying to [comment:4 rwbarton]:

Use Linux? :) Sorry, I have no Windows experience and no access to a Windows machine.

I hope that was not offensiwe (although I feel it was). We cannot convert all the people we address the software to use Linux, can we? Additional I thought GHC is ment to be serious - cross-platform compiler, so I think solving this bug is somewhat important for everybody. We've got some windows expirence and people that can help you (but they are not haskellers) additional I can provide you any time remote machine on Amazon with everything configured - you could connect to it and check the things out. We will help you as much as we can also - what do you think? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9907#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: #7056, #8546 | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- * architecture: x86_64 (amd64) => x86 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9907#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: D671 #7056, #8546 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"a293925d810229fbea77d95f2b3068e78f8380cc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a293925d810229fbea77d95f2b3068e78f8380cc" rts/linker: ignore unknown PE sections Summary: Currently the linker tries to see if it understands/knows every section in the PE file before it continues. If it encounters a section it doesn't know about it errors out. Every time there's a change in MinGW compiler that adds a new section to the PE file this will break the ghc linker. The new sections don't need to be understood by `ghc` to continue so instead of erroring out the section is just ignored. When running with `-debug` the sections that are ignored will be printed. Test Plan: See the file `ghcilinkerbug.zip` in #9907. 1) unzip file content. 2) open examplecpp.cabal and change base <4.8 to <4.9. 3) execute cabal file with cabal repl. Applying the patch makes `cabal repl` in step 3) work. Note that the file will fail on a `___mingw_vprintf` not being found. This is because of the `cc-options` specifying `-std=c++0x`, which will also require `libmingwex.a` to be linked in but wasn't specified in the cabal file. To fix this, remove the `cc-options` which defaults to c99. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D671 GHC Trac Issues: #9907, #7103, #10051, #7056, #8546 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9907#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: Phab:D671 #7056, #8546 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via ad628657cd56362964d17677728f4ae4d6868613). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9907#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: Phab:D671 #7056, #8546 | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) Comment: I have been trying something similar, but then I encountered another error: `unhandled PEi386 relocation type 3`. Looking at the code there is indeed no case for relocation type 3 which unless I'm mistaken is: IMAGE_REL_AMD64_ADDR32NB 0x0003 The 32-bit address without an image base (RVA). But curiously while trying to understand what the linker is doing (and I may have the wrong idea since I'm new to this part) I see under the `x86_64` cases this `case 17: /* R_X86_64_32S */`. However in the PE doc I can't find any relocation type `0x0011`. So am I looking at the wrong place or should this have been `0x0003`? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9907#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: Phab:D671 #7056, #8546 | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9907#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Revisions: Phab:D671 #7056, #8546 | -------------------------------------+------------------------------------- Comment (by Phyx-): @thoughtpolice Yes there will be a fix :) I have changed the code to identify most of the sections based on the flags in the PE file instead of the section names. So we don't have to keep a list of white-listed sections, so it should be much more resilient to changes. The only sections still being ignored by names are a few debugging ones, but it's fine since those are reserved names and currently we don't do debug section relocations. I'm just trying to find where the constant 17 comes from, but from looking at the generated .s files, I think this might be a bug in GAS. I'll submit a diff this weekend after I finish checking if the related bug reports are also fixed :) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9907#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Rev(s): Phab:D1244 #7056, #8546 | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"620fc6f909cd6e51b5613454097ec1c9f323839a/ghc" 620fc6f9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="620fc6f909cd6e51b5613454097ec1c9f323839a" Make Windows linker more robust to unknown sections The Windows Linker has 3 main parts that this patch changes. 1) Identification and classification of sections 2) Adding of symbols to the symbols tables 3) Reallocation of sections 1. Previously section identification used to be done on a whitelisted basis. It was also exclusively being done based on the names of the sections. This meant that there was a bit of a cat and mouse game between `GCC` and `GHC`. Every time `GCC` added new sections there was a good chance `GHC` would break. Luckily this hasn't happened much in the past because the `GCC` versions `GHC` used were largely unchanged. The new code instead treats all new section as `CODE` or `DATA` sections, and changes the classifications based on the `Characteristics` flag in the PE header. By doing so we no longer have the fragility of changing section names. The one exception to this is the `.ctors` section, which has no differentiating flag in the PE header, but we know we need to treat it as initialization data. The check to see if the sections are aligned by `4` has been removed. The reason is that debug sections often time are `1 aligned` but do have relocation symbols. In order to support relocations of `.debug` sections this check needs to be gone. Crucially this assumption doesn't seem to be in the rest of the code. We only check if there are at least 4 bytes to realign further down the road. 2. The second loop is iterating of all the symbols in the file and trying to add them to the symbols table. Because the classification of the sections we did previously are (currently) not available in this phase we still have to exclude the sections by hand. If they don't we will load in symbols from sections we've explicitly ignored the in # 1. This whole part should rewritten to avoid this. But didn't want to do it in this commit. 3. Finally the sections are relocated. But for some reason the PE files contain a Linux relocation constant in them `0x0011` This constant as far as I can tell does not come from GHC (or I couldn't find where it's being set). I believe this is probably a bug in GAS. But because the constant is in the output we have to handle it. I am thus mapping it to the constant I think it should be `0x0003`. Finally, static linking *should* work, but won't. At least not if you want to statically link `libgcc` with exceptions support. Doing so would require you to link `libgcc` and `libstd++` but also `libmingwex`. The problem is that `libmingwex` also defines a lot of symbols that the RTS automatically injects into the symbol table. Presumably because they're symbols that it needs. like `coshf`. The these symbols are not in a section that is declared with weak symbols support. So if we ever want to get this working, we should either a) Ask mingw to declare the section as such, or b) treat all a imported symbols as being weak. Though this doesn't seem like it's a good idea.. Test Plan: Running ./validate for both x86 and x86_64 Also running the specific test case for #10672 make TESTS="T10672_x86 T10672_x64" Reviewed By: ezyang, thomie, austin Differential Revision: https://phabricator.haskell.org/D1244 GHC Trac Issues: #9907, #10672, #10563 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9907#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler