Sure, but if the reason for the group is to add structure to the help output, I think that is a reasonable thing to state in the commit message. The other options are ... well, either not meant to be part of the commit as per the commit message or the commit message should be updated to indicate that they are being added (and why they are part of structuring the help output, assuming that is the reason for the group). The changes requested are requests for clarification :)

I can sympathize with the desire to avoid the undecoration. Unless @ldionne has some reason why this is a poor choice to support, this seems okay to me.

Looks reasonable enough to me. Please ensure that @ldionne is okay with it as well.

I like the clean up here, but, I think there is some value in retaining the defensive sanity checks. You are correct that in most cases, this should never be hit in a proper unwind, but because this may be run in a last chance scenario, having the defensive checks is good for catching things going wrong.

Seems like this just adds an option to control a hardcoded value, which is reasonable.

Perhaps @rnk has any thoughts, but this seems very straightforward.

Welcome back, hope you had a good time off. Thanks for the review!

Could you please add a test case for verifying the output order of the load commands? It seems that the load commands are expected to be in a certain order according to your change - it makes sense to have a test which validates that ordering.

This adds additional options while also adding a group for the versions. Is there a reason for the group to be added? Can you please either remove the newly added options or adjust the commit message? I think that there should be some reasoning given for the version group creation (at least, it isn't clear to me why the group is helpful/necessary, unlike in clang where the group can be used to silence warnings).

Ping x 3

I agree with Renato, this seems incorrect. In the EABI mode, we should prefer the EABI symbols.

In D90898#2384775, @rprichard wrote:

In D90898#2379387, @compnerd wrote:

Could you add a bit of a comment explaining why the XOM case is not protected against?

I think I can expand on the comment.

libunwind can be used for generating backtraces during regular execution (e.g. profiling) and crashing if the XOM is in use seems unfortunate.

For profiling, I assume the unwind info needs to be accurate at every instruction? I know that's definitely not the case for AArch64, but I thought it's still only mostly-accurate on other archs? I don't *really* know that unwinding through a signal handler is important for Android, but I don't know how to rule it out either, and we do have a test for it. I think the test predated Android's libunwindstack unwinder. Maybe someone could be using _Unwind_Backtrace in a segfault handler, and that probably avoids the async-unwind-info problem most of the time. But I also don't think that's how third-party Android crash dumpers work.

You mean use armv7---elf as a triple? While that is possible, keep in mind that it might change the ABI of the generated interfaces. While it is unlikely to matter as the ifso cannot be used at runtime, if the linker attempts to do something like symbolic resolution of ABI dependent specialization (e.g. strcmp.eabi vs strcmp where the latter is generic), that could matter. However, adding support to explicitly override the encoded triple based on the user's input is reasonable (though might deserve a warning that the triple is being overridden).

The full triple is needed in some cases: armv7-unknown-linux-gnueabi vs armv7-unknown-linux-gnueabihf vs armv7-unknown-linux-eabihf vs armv7-unknown-linux-eabi are all different. Additionally, there is nothing that prevents you from doing something like: armv7-unknown-linux-gnueabihf-coff or armv7-unknown-linux-gnueabihf-macho to generate COFF or MachO object files that are reading in additional bits of ABI information and the libc from the target triple. I really think that preserving the target triple is best.

I think that it makes more sense to ignore the aapcs-vfp calling convention attribute (returning CCCR_Ignore), and warn on the aapcs. The redundant calling convention attribute does nothing, and I think that simply ignoring it would solve your issue. However, changing the calling convention to aapcs would break interoperability, so warning on that seems reasonable still. I think that if Wine is willing to adjust their use of the attribute, that would really be nicer - it allows us to keep the behaviour as close to MSVC as possible.

Ping x 2

Can you please add some more context around the motivation for this change? It seems ... unnecessary as everything is already AAPCS/AAPCS-VFP.

LGTM; please fix the formatting lint.

Thanks!

Gentle post-holiday ping :)

The change on L722 took me a few moments to catch - that was subtle.

Nice cleanup!

I really would prefer the alternate spelling, but the change itself is okay.

Ping

Hmm, I think that the function is marked as noexcept, so the the funclet shouldn't be invoked and should get DCE'd, but that seems unrelated to ARC.

There is nothing particularly special about that. The reason for the funclet handling there is that in the case of an outlined block for exception handling (i.e. a funclet), we need to ensure that the assembly marker received the funclet token as failure to do so would mark the assembly as unreachable and would thus thwart the auto-release claim. For the normal codepath, the behaviour should be identical.

I think that it makes sense to merge this with D92911 and D92912

Does this make sense to have as part of a single commit with D92912 to have a change to populate the LTO configuration options?

I wonder if there is a good way to enumerate the desired set of options (e.g. -O is currently missing), but I don't think that there have been too many attempts to flesh out the argument handling, so we can hold off on that until we find that we have had to do this a few times.

I think that once the LLVM backend target is merged, it would be reasonable to commit this change. The target being experimental is fine, but it should be available. (Marking as requesting changes until the backend is merged).

Maybe I am missing something, but it doesn't seem to be supported in llvm yet:
https://github.com/llvm/llvm-project/blob/main/llvm/CMakeLists.txt#L302-L320

Interesting, I expected a large fallout. I think I agree with @thakis that this is preferable to D92455.

Seems fine to me. Does the output match what ld64 does?

Following the ACLE is definitely preferable. One thing to verify is if gcc does support this correctly as well. IIRC, it does support __ARM_FP properly and this should be safe, but please do verify that.

Nice! Thanks @thakis, this is a rather useful debugging aid (for users of the linker).

That really is unfortunate. LLVM generally does a pretty good job of sticking to standard C++. The symbols you claim are missing aren't C++ symbols but rather C symbols. I suppose that this doesn't hurt the other targets.

The change itself is fine, though I think that the commit message can be improved. The shuffling of the code should be called out in the summary IMO.

I still don't really like the environment variable approach to the testing.

Gentle post-holiday reminder :)

Thanks!

Would be nice to actually mention that in the commit message and adjust the condition to indicate that (!defined(__MINGW32__) && !defined(__MINGW64__)).

I don't think that we can use llvm-libc, but I suppose that lifting the functionality from there is possible. What does that gain over this though?

I don't have an objection to the change, but would like more details added to the commit message. It is unclear to me why the change is needed as clang does accept this I believe (and a quick test seems to indicate so as well).

Thanks @Bdragon28, this definitely is a nice cleanup (and fix). Please remember to fix the #elseif to a #elif.

I'm not convinced that making this an option is valuable at this time. Right now, I don't think that this functionality is broadly adopted, and, I suppose that if your linker is clever enough to perform optimizations thoroughly enough, it wouldn't matter too much (modulo link time explosion). I would like to see this more accurately explained in the documentation though - CodeGenModule.cpp L423-L424 would be a good site for that. Beyond that, LGTM.

Address review comments

Im not sure if renaming the check prefix is actually helpful, but sure. This does seem like somewhat unfortunate. For the dllexport case, you really want dso_local. define dso_local global and declare dso_local global are preferable in this case as that guarantees a local definition, which is always the case for an exported symbol. You definitely do not want declare extern dso_local global. A few of the changes here are actually changing the IRGen from the desired state, is that intentional?

Ping; I'd let to get this sorted out so I can continue to make progress towards serialization and deserialization.

@martong since you hard expressed interest in the "user-visible" version of the data types for the notes, I opted to get them out first. This set of data types are user-facing rather than the previous one that were mistook for them. Subsequent changes will actually add interfaces to APINotesWriter which will allow you to add new information to the writer to serialize out.

Could you add a bit of a comment explaining why the XOM case is not protected against? libunwind can be used for generating backtraces during regular execution (e.g. profiling) and crashing if the XOM is in use seems unfortunate. We could check the memory mapping and just give up in the XOM case.

@thakis, thanks for the heads up, I've disabled the test on Windows - I should've disabled it on Windows in the first place.

Thanks for the reviews! I'll reformat the rest of the code before merging. Im going to be working on merging this downstream first before merging this upstream, so it will take a couple of days still.

rebase, clang-format, add comments