LGTM

Some cleanup suggestions included, but I like the change overall.

I'm not sure I understand this. The proper location for libc++ on the darwin layout is in the SDK, not relative to the driver. The default behaviour is similar to cross-compiling, and with a (derived) SDK. This definitely needs to be reviewed by @dexonsmith

Snipping bits from va_defs.h:

I definitely like the clean up. Not sure I understand the motivation for the __libcpp_relaxed_store, but I suppose thats because its a copy from libc++ where it may be more useful.

Sorry for the delay, didn't see the changes earlier.

I know that the Windows SDK definitely declares the __va_start function. Did you try building something like swift against the Windows SDK with this change?

I really don't like this approach. I think that we should introduce a different entry point for this behavior rather than saying that we go through the existing interface. Having a reference to the .eh_frame_hdr seems better, as it would be better to make use of that optimization and we already have handling for that in libunwind.

I may be a bit biased but I agree with @bob.wilson and @steven_wu. The current names are better from the user’s perspective. GCC’s build is a very bad example as it has runtime components built as part of it (libgcc). When building any code, even in a Canadian cross-compile, the target will always be what you are running on. The preprocessor macros are part of the code that you are building for a given target. The association with the command line option makes it more obvious what it is going to use to determine the value. Having a pithy name should also be considered a design goal. Recreating new terminology only muddles the problem.

I want to get Duncan's input on this. I don't think that this is a supported configuration for macOS.

LGTM, I'd give @majnemer a day or so before committing.

What happens in the case that you have a variadic in C code marked with __forceinline? Does that also cause a warning with MSVC?

SVN r327336. Addressed comments in SVN r327351, because I forgot to incorporate them in the first try.

Use the BB colorizer to detect the token. Fortunately, there is no BB removal/splitting happening here, so there is no state to maintain.

SVN r327105

SVN r327082

add more context

@rnk, I like the idea of pushing the mapping behavior to the single use in llvm-pdbutil and removing this overload.

Awesome, thanks, this makes me feel much more comfortable.

Ugh, really not a fan of this change.

SVN r326362

Yeah, this is still an indirect return. I can see your point about the representation, nfortunately, I think that change is way out of scope for this. That would be a pretty large and invasive change to wire that through.

If its easy enough to wire that through to the frontend as a proper diagnostic, that would be better with a test. Otherwise, this is good to continue to make progress.

SVN r325724

Update comment

Yeah, I think I would feel safer with this being limited to targets where we know that we have an explicit contract for __int128_t. Can you please limit this to the RISCV architecture for the time being?

Please clang-format the conditional (we keep the operator on the previous line).

Is there a need for this given the changes for 6.0?

SVN r324701

@rjmccall, I've updated the approach and no longer abuse the existing decoration styles. This uses a custom namespace with artificial types to differentiate the types. I've also ensured that the parameter types do not encode the type information.

Address comments from @rjmccall

I think we should first clarify that currently the only Windows on ARM support is Windows ARM NT (Windows ARM CE still does have both modes of execution). The important thing to note here is that although the CPU supports both modes of execution, the Windows ARM NT kernel does not guarantee the current mode will be preserved (that is, if you trap into the kernel in ARM mode, you are probably going to come out in Thumb mode and fault). I agree that we should try to fix this generally rather than hardcode this to Windows ARM.

@aaron.ballman, yeah, I believe that the warning is working as intended, it just so happens that at runtime things just happened to work out.

SVN r324439

SVN r324438

Update to what Microsoft has communicated offline

address design changes

Add additional test, update docs

@jhenderson I believe that the first one is what this is implementing. I believe that adding the last two as a patch following this one is preferable as that is specific to the needs for PS4, but, both of those should be possible to accommodate. I would love to see a single unified approach here, so Im happy to help get that implemented.

I believe that the commit message needs to be updated for the change. This is a pretty distasteful patch IMO, but, I don't see a better solution here :-(.

@jhenderson I believe that you are correct with the analysis of the behavior of binutils' objcopy. Definitely should have a test case for this.