#15051: -split-objs generates excessively many files on Windows -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Phyx- Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (CodeGen) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4915 Wiki Page: | Phab:D4916 -------------------------------------+------------------------------------- Comment (by Phyx-):
I've noticed this problem too, but I'm not sure getting rid of split- objs is the solution. The problem, it seems to me, is that it's (a) splitting with a Perl script, and (b) calling gcc with each and every single individual file produced.
Is it possible to get rid of the Perl script, at least on Windows, by specializing the split-objects procedure for Windows x86/x64 builds and
Actually, now that I think about it, why is it even using gcc to convert
(a) is not the problem. The perl script just does a simple linear scan looking for split markers and breaks it up. The overall runtime of the split script is negligible. (b) It won't work without this. split-objs just exploits the fact that linkers pull in library code on demand. If no symbols in an object file in an archive is needed it's not pulled in. split-section uses "linker stubs" to get the same effect, the tiny object files are pre-linked together to get one giant object file where each original .s file is a new stub. Passing all the .s files to the assembler will cause it to merge the contents of the sections and you'd get one linker stub. The net effect would be the same as not splitting to begin with. While you could force the creation of a linker stub with a `.file` directive for each part, the result still won't be the same as your `.text` section header will still be merged. then using gcc to build many assembly files at a time? Not really, as I've explained above. the assembly files into object files in the first place? Doesn't it convert the code directly into an object file when split-objs isn't used? No, GHC doesn't have an assembler or static linker. It always uses an external program for both of these cases. It only has a runtime linker for GHCi and Template Haskell. As it stands, `-split-objs` is simply a dead approach, it's better to invest the time into getting `-split-sections` working, which doesn't rely on hacks. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15051#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler