- User Since
- Mar 30 2013, 6:49 PM (521 w, 3 d)
Jan 24 2019
Sorry for the delay.
The change from BLOCK to ALIGN is now accepted upstream.
Closing this and thanks @grimar
Dec 23 2018
I'm not sure if we should change the linker script or add BLOCK
Dec 21 2018
This was already implemented in rL349511 and rL349772.
Thanks @sfertile and sorry for the noise.
I don't know if there are any notes here that are useful. --got-optimize ?
Dec 10 2018
Dec 9 2018
I'm probably going to learn something valuable about the global offsets table or the table of contents sections from the response to this :)
I implemented this for ppc32 as well but there are a few things that need to be changed as a result of this so I will put that in a separate patch
I'm going to add a bunch of inline comments about things that could change.
Tracking issue for clang built linux for @nickdesaulniers
Dec 4 2018
Also, Sorry for the long time to reply, I don't LLVM often enough :)
Seems like a better solution than what I had in D37726.
I'm not sully sure on the naming so I think someone else should also sign off on this.
Dropping in favour of D53238
Sorry only getting around to this comment now. I think this is probably what you are looking for
Dec 2 2018
This probably needs another approval based on the small changes I made to address the warning
update to address comments
Nov 24 2018
Nov 22 2018
I really hope gn catches on and it also works with the tools layout ( i.e. llvm/tools/lld ) so I can make good use of ninja -C out/gn check-lld. :)
Apr 22 2018
Apr 4 2018
@mstorsjo I would much prefer to detect the clang sysroot first and if that exists just ignore the gcc one.
Most of the time clang and gcc will be in the same bin folder and in the case where the clang sysroot with mingw prefix folders is not found we can just default back to the default gcc behavior.
This should cover the use case for existing gcc users while not blocking us to move forward with clang only toolchains.
If someone really wants to ignore the clang sysroot with mingw folders we could add a flag for that and not the other way around.
What are your thoughts here?
Mar 23 2018
Mar 11 2018
@alexcrichton can you confirm this works as a replacement for your partial revert here https://github.com/rust-lang/llvm/commit/9eb9267 ?
Mar 10 2018
Mar 8 2018
Feb 21 2018
Feb 20 2018
Sorry for the delay,
I looked back on this a few times and I don't have the relocations to support doing a full round trip.
It does seem however that tests are only done for the 4 fully supported arch's.
see obj2yaml.test for reference.
Glad to see this finally get approved :)
@marsupial do you have commit access?
Feb 7 2018
Updated to just ignore the flag just like how clang-cl does for /bigobj
Jan 20 2018
This seems to work better then what I have in D41580 for llvm_config.
Jan 17 2018
Err, I mean Sam, Sorry.
Jan 13 2018
Given that https://reviews.llvm.org/rL322380 has been merged this seems good to me.
Jan 2 2018
We should be able to add it as an ignored flag much like the /bigobj flag for clang-cl
Since rL217812 clang implicitly creates bigobj files when needed.
Will update to reflect when I get the chance.
Dec 27 2017
Dec 26 2017
Dec 25 2017
Dec 24 2017
hmm, looking at the #define for NO_EXEC_STACK_DIRECTIVE
once the two files have been removed from non windows targets they won't do anything anymore.
Also noting my comment on 35739
Dec 1 2017
Nov 28 2017
The default is now configurable in mingw-w64
we have come a long way since then @ruiu :) , abandoning a really old revision
I also want to note a small addition armeb and thumbeb for NetBSD.
They were missed in the previous version.
Just waiting for tests to pass now.
@mstorsjo yup, I added a comment on the commit about the failure here rL319294
I have already fixed both issues.
Will re apply shortly.
seems the windows sanitizer bot does not like seh on i686
going to revert and re apply with None for x86
landing this as it was previous approved by reid in this state and again re checked by martin.
- disregard my last comment, lets go with seh on all windows targets.
address reid's comment
update to HEAD
Nov 22 2017
fold USESjLjExceptions into GetExceptionModel.
do a best effort to check the llvm default exception model for the triple if the toolchain does not specify.
(mostly based on the cc1_as code)
Nov 21 2017
Just as a note there is still a lot to be desired here. I do not particularly like the UseSEHExceptions function default and the actual macro definition guards should be based on the current ExceptionModel because we set that in lib/CodeGen/BackendUtil.cpp. This way we do not need to have some silly default of x64 && windows for UseSEHExceptions and can rely on the llvm backend defaults but override within the driver we want like the apple targets do for sjlj. This does for now keep the current functionality while giving us a flag to override which is the goal of this patch.