Sorry for the delay.
The change from BLOCK to ALIGN is now accepted upstream.
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=a652758ac1475f69d28d11b3528c4f48
Closing this and thanks @grimar

I'm not sure if we should change the linker script or add BLOCK

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 ?

add context

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
https://github.com/ClangBuiltLinux/linux/issues/285

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

In D54871#1307606, @grimar wrote:

(I did not find how the macro DISCARDS expands in
https://github.com/spotify/linux/blob/master/arch/powerpc/kernel/vmlinux.lds.S#L262)

Sorry only getting around to this comment now. I think this is probably what you are looking for
https://github.com/torvalds/linux/blob/master/arch/powerpc/kernel/vmlinux.lds.S#L387

This probably needs another approval based on the small changes I made to address the warning

update to address comments

update tests

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. :)

LGTM

@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?

@alexcrichton can you confirm this works as a replacement for your partial revert here https://github.com/rust-lang/llvm/commit/9eb9267 ?

ping @marsupial

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.
IMAGE_FILE_MACHINE_I386
IMAGE_FILE_MACHINE_AMD64
IMAGE_FILE_MACHINE_ARMNT
IMAGE_FILE_MACHINE_ARM64
see obj2yaml.test for reference.

Glad to see this finally get approved :)
@marsupial do you have commit access?

Updated to just ignore the flag just like how clang-cl does for /bigobj

This seems to work better then what I have in D41580 for llvm_config.
LGTM.

Err, I mean Sam, Sorry.

In D33753#975343, @sbc100 wrote:

My problem is that HandleLLVMOptions seems to add a lot of compiler and system check.... seemingly more than are required to build libcxxabi. It seems like by including this line we are maybe needlessly restricting the set of compilers/environments on which it can be built.

Given that https://reviews.llvm.org/rL322380 has been merged this seems good to me.

In D41597#964538, @rnk wrote:

Looks good. Maybe we should also fix clang to accept this flag, though?

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.

In D41580#964147, @hintonda wrote:

I like your idea, but can't you do this without adding new flags?

You already have to pass -D(CLANG|LLVM)_TABLEGEN which prevents them from getting built. llvm-config is a little different in that you need to pass -D_LLVM_CONFIG_EXE since project is undefined in tools/llvm-config, but adding a test for ${project}_LLVM_CONFIG_EXE is consistent and should work as well. Perhaps this needs to be refactored as well, so you can pass -DLLVM_CONFIG_EXE instead of -D_LLVM_CONFIG_EXE.

Landed in rL321447

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

The default is now configurable in mingw-w64

ping

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
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/20371/steps/run%20check-asan/logs/stdio
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

In D39673#931861, @rnk wrote:

We have to know the EH model before pre-processing, and that shouldn't rely on LLVM TargetOptions. We can probably reuse the llvm::ExceptionHandling enum instead of these various overlapping booleans, if that's the direction you want to go. However, I don't see how we can get away from the clang toolchain knowing the default EH model for each target.

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)

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.

In D39673#929986, @mstorsjo wrote:

I'm not sure if this is the right thing to do. Since the exception handling model more or less also defines what ABI the code conforms to, I can see it being useful to know what exception handling mode is intended to be used, even if compiling plain C code without exceptions enabled. E.g. when building libunwind, some of the C sources there have ifdefs that check for __USING_SJLJ_EXCEPTIONS__ and/or __ARM_DWARF_EH__. With this change, one has to manually start specifying it when building libunwind, to match whatever the default and/or manually chosen exception handling model is.