Just to clarify, this is needed for the triple-prefixed tools, but the triple-specific directory worked fine before this patch? If I'm understanding that correctly then LGTM, otherwise I'm confused as to why I haven't seen this problem before.

https://github.com/llvm/llvm-project/commit/19fd9039ca242f408493b5c662f9d908eab8555e

https://github.com/llvm/llvm-project/commit/626260cfe3c7a5d9747f0bf13d87fa1855eb74bb

LGTM

Fix a couple missing bits in the instructions.

In D68968#1710520, @labath wrote:

Independently, I am wondering if there's a better way to link the process id to a bundle. Using argv[0] might be ok if we're using it just for display purposes, but if we're going to be doing other stuff based on that identifier, it would be better to get it from a more reliable source. Unfortunately, I was not able to find a more "reasonable source", but maybe @danalbert has an idea.

The alternative would be to only provide new/delete inside libc++abi, not in libc++ (by default). So, vendors (@phosek @srhines @danalbert @dim @emaste), are you OK with the default becoming that libc++abi provides new/delete, and libc++ DOES NOT (by default). If you want to keep shipping new/delete as part of libc++, you'll need to specify -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON at CMake configure time.

If the Android and FreeBSD folks are ok with this, I'm fine with it

Thanks for the heads up. I've reverted the patch.

Closed by https://reviews.llvm.org/rL372016

LGTM. @EricWF any further comments before I submit this?

Otherwise LGTM

MSan won't currently help us on Android (and I don't think there's a plan to support that any time soon, but eugenis would know better).

I think for Android we'd rather have the debuggability, but +enh for a second opinion.

For example, when we're building against the Android NDK, we might want to use the NDK's C++ headers (which have a custom inline namespace) even if we have C++ headers installed next to the driver.

@EricWF ping

@EricWF Any concerns, or can I merge this?

Only opt-in for bionic

I'm not really sure who speaks for glibc platforms. @EricWF? Like I said, if we're not comfortable making this change for glibc I don't have a problem backing that out, but I do think this is a more useful default behavior. It's fairly convoluted to pass a file descriptor from an fstream across an exec boundary intentionally so I somewhat doubt anyone is doing so intentionally. Anyone doing so unintentionally is just leaking an fd and any use of it on the other side of the exec is probably a bug.

Add a comment explaining _LIBCPP_FOPEN_CLOEXEC_MODE.

Ping?

Android maintains its own build scripts, so this won't harm us, but I think the problem in general remains. Seems like it would be better for the webasm target to opt out of the behavior than for all targets to do it (or maybe just provide an option so maintainers can choose what they want for their platform).

In D59839#1444061, @mclow.lists wrote:

I'm mostly worried about the change in behavior breaking existing programs.

In D59839#1443731, @mclow.lists wrote:

How did you decide which modes fell into "when possible"?

Updated to address some review comments:

In D58153#1395601, @efriedma wrote:

The official documentation still says "Your app must perform runtime detection to confirm that NEON-capable machine code can be run on the target device" (https://developer.android.com/ndk/guides/cpu-arm-neon#runtime_detection). Is that wrong?

Added reference to spec in comment.