Mar 22 2019
Mar 20 2019
Mar 4 2019
Jan 7 2019
Oh sorry, I had forgotten to commit this. I'm afraid I haven't sorted out my commit access to the new repository yet.
I'm not really sure what the process now is... Could I ask you to move it to gitlab? point to this review and I'm sure someone will commit it. I'll try to sort out my access this weekend.
Dec 19 2018
Hrm.. slightly confused... I'm pretty sure @angerman had the exact same patch last year... but lgtm, this code is no longer on the critical path so don't mind it becomes slower...
Dec 8 2018
I don't know if it's related, but I tried twice but the build seems to fail with
Just some small comments, I am waiting on the build to finish.
Dec 7 2018
Sure, I will take a look after work today
Dec 4 2018
skip test when not dynway
Dec 3 2018
Seems to build a ghc on macOS.
Previous issue was gcc/binutils and llvm/clang/xcode crossing paths.
Dec 2 2018
It doesn't build for me; bails out with some rather weird linker errors.
I wouldn't put it past my system to be screwing me over here. I'll have to try in a clean room install again.
@alpmestan @harpocrates Thanks, From looking at the harbormaster build logs none of the linker tests that failed last time failed, and also this change should be find in that regard. So if it's ok with you @alpmestan it's fine with me too :)
Next time for filtering like this though please use the normalisation facilities in the testsuite, that's a lot less fragile because the state of these core-utils programs tend to differ
between OSes, and they can be shadowed depending on the user's environment.
Nov 29 2018
Yup that's fine, thanks!
Nov 28 2018
I think for the file in question we also generate a C stub for stable pointers.
It might happen when combining the stub and haskell code into one object file?
what exactly was the error that made you think this was needed @bgamari ?C://ghc//msys64//home//Andi//ghc_head//inplace//mingw//bin/as.exe: C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: too many sections (32801) C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Assembler messages: C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Fatal error: can't write 4 bytes to section .rdata$c1w2b_str of C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o because: 'File too big' C://ghc//msys64//home//Andi//ghc_head//inplace//mingw//bin/as.exe: C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: too many sections (32801) C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Fatal error: can't close C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: File too big `gcc.exe' failed in phase `Assembler'. (Exit code: 1) make: *** [libraries/template-haskell/ghc.mk:4: libraries/template-haskell/dist-install/build/Language/Haskell/TH/Syntax.p_o] Error 1 make: *** Waiting for unfinished jobs.... make: *** [Makefile:128: all] Error 2
Yes, because of --oformat,pe-bigobj-x86-64, --oformat is used to set the output format, but there isn't such a format for PE (the name in bfd is a bit misleading). The bigobj is as the name implies a COFF format, e.g. only for object files.
--oformat,pe-bigobj-* is only needed if you're doing pre-linking with -r. For the final PE binary, there's no way you should have no# sections anywhere near the limit of of the PE file anyway, as the linker would have merged the subsections again.
@angerman would it be possible for you to check if this compiles for me on MacOS? It's not a platform I have access to. Thanks 🙂
Nov 27 2018
This is fine, I'm surprised the linker flag is needed though. Seems like an LD bug. Only question I have is about the 32 bit builds, I'm assuming non-prifiling builds don't have this issue but now gas will ignore -mbig-obj but ld will probably error out.
Nov 22 2018
@alpmestan no worries :) just a few more failures I need to look at and windows validates cleanly again.
Nov 21 2018
Is there any outstanding work here or is everyone happy?
LGTM, thanks @trommler
Nov 20 2018
Move test changes to other diff
Add some more tests
Thanks @alpmestan the tests now pass again!
Nov 19 2018
Thanks @alpmestan I'll kick off a build to check.
Nov 18 2018
Prevent builtin expansion.
Oct 27 2018
Oct 26 2018
Thanks @sheaf ! This looks good. Just one final small change and I'll accept it, you can combine the two list to simplify it,
move loc' to the same level as loc and combine them.
Oct 25 2018
@RyanGlScott Yeah, looking at that ticket (same one @sheaf posted) seems to indicate that they are supported. I think you misunderstood the ticket @sheaf in that what it was attempting to solve was
that when DynWay isn't available, then ProfWay can't be either for plugins. But if Both DynWay and ProfWay are specified then it should work.
I think you were right, much better to directly search for library paths instead of going through "packageHsLibs" and messing with the DynFlags to get the output we want. I hope this hasn't messed with anything on other platforms! It's working on my end (on Windows) at least.
Oct 24 2018
Hi @sheaf Thanks for the patch.
Oct 23 2018
Oct 5 2018
Oct 3 2018
- rebase and checked rest attributes
Oct 2 2018
@watashi Thanks, that makes more sense. The behaviors are different so for now splitting them up is fine, Add a /* See Note [loadOc orderings]. */ in front of the PE one.
I think I'll just move the call into ocGetNames_PEi386 so that Linker.c doesn't diverge. But for now this is fine. Thanks!
I don't know which dangling pointer you're talking about.... If it's something your change introduced then you must take care of it there. flipping the order like this will just segfault on stage2 on Windows.
ocAllocateSymbolExtras_PEi386 accesses oc->info->image https://github.com/ghc/ghc/blob/5840734379da5d494a368d0b8a6edf1b1216a7f4/rts/linker/PEi386.c#L1785 which is set in ocGetNames_PEi386 https://github.com/ghc/ghc/blob/5840734379da5d494a368d0b8a6edf1b1216a7f4/rts/linker/PEi386.c#L1579 if the linker decides it's going to keep the object file. So I don't see how flipping the order can work at all.
Sep 28 2018
Thanks @alpmestan that's fine. I made a ticket for it on trac in the mean
Sep 26 2018
Sep 25 2018
Sure thing,I'll update the patch later today.
Sep 24 2018
Sep 23 2018
This change doesn't play well with our habit of exporting all symbols into shared libraries. --export-all-symbols combined with the -Wl,-u will end up making the linker a) always export the symbol and always pull it in.
This means compiling a library with -shared on Windows will result in a library that can't be used to link against others.
Sep 17 2018
Thank you @angerman !
- rebase and add comment to loadOc
Sep 15 2018
@angerman Mind giving this a review for me? thanks!
- fix comments and made some fields const
Sep 11 2018
Sep 8 2018
Ping, this version is ready for review..
Aug 29 2018
Thanks @RolandSenn ! looks good to me.
Aug 28 2018
Aug 27 2018
Aug 26 2018
ok, how about something like Error while parsing OPTIONS_GHC pragma, expected whitespace delimited list of options. Input was " -O1 }\n\"\n "
Aug 25 2018
Aug 23 2018
Hmm right, gold does support --relax, jus not --no-relax, maybe just
add a new test for this and just wire it through like LdIsGnuLd. I think
we might be using that one for split-sections support to? Not sure, haven't
checked what else it's used for.
Aug 22 2018
Oh, that's unfortunate. --no-relax is very old flag in binutils (ld.bfd) and sparc did --no-relax forever.
Sounds like we will need to extend the driver to query $LD at runtime to check for --no-relax support.
GHC seems to have become so fat that the extreme amount of memory we're wasting with the usage of VirtualAlloc means we quickly eat up the lower 4GB of virtual memory. This means the trampolines are allocated outside the 4GB range and are thus useless.
- fix use after free for import libraries
- fix trampoline calculation.
The windows build is stuck restarting. can an administrator unstick it please?
Aug 12 2018
@bgamari I have been spending the majority of my time on the I/O library. So I have reverted this patch to an earlier state that should be finished and want to get this one in for the next GHC for sure.