For now, only Linux/ARM64 is supported/tested.

I think it's ok to only warn on Windows.

IMO that's sensible

Seems reasonable to me

Ah, of course. SGTM.

No objection here. I'm curious why the two modified tests work on Linux or NetBSD today though?

How do things go wrong on Darwin? I was under the impression that this was implemented in LLVM as strictly inline code, no runtime support required.

One thing that FreeBSD should do, is to upgrade to the protocol version 1 (stored in r_version), like Linux, NetBSD and OpenBSD.

Link to Linux info:
https://sourceware.org/gdb/wiki/LinkerInterface

I'm curious how gdb handles this, and asked @bsdjhb if he knows off hand.

No objection, but maybe add a comment explaining the status of this implementation? Does/will NetBSD do the same?

Can we add a test that the feature can be enabled on an OS other than Linux / Windows / Darwin?

Abandon in favour of D92245

Perhaps

if (EffectiveTriple.isOSWindows() || EffectiveTriple.isOSDarwin())
  return;

here too

• add comment suggested by @rnk
• combine Linux and FreeBSD FileCheck

Looks ok to me

I'm not sure if we need to add a runtime check?

This is fine with me; have we always done that?

No objection from me but I haven't been sufficiently involved in lldb's tests to approve.

Agree that even if refactoring is needed correcting these makes sense.

In theory Obj-C is available on other systems

How does Windows fit into this? Other than that Q, LGTM.

Does Linux fetch each time also?
I agree it's probably not worth the effort.

What do you suggest? Is it fine to go with my results for as long as I work on it? I can update it to match CI/buildbot results later.

When running locally with this change applied I get:

I added comments in the now-dereferenced bugs linking back to this review - most of them were submitted by me, and I'll double check and close them once this lands.

There is TestProcessAttach.py that has an @expectedFailureNetBSD but no FreeBSD annotation, as well as TestCompletion.py, but I don't see these in the failing list.

running clang -target x86_64-unknown-freebsd13.0 -split-dwarf foo.c indeed produces a foo.dwo and foo.o w/o invoking objcopy

LGTM

Looks fine to me

Looks reasonable to me and currently fails (as expected) on FreeBSD.

Looks OK

fine with me

fine with me

It looks like this conflicts with OpenSSL's compiler version check

• https://svnweb.freebsd.org/changeset/base/364822
• https://lists.freebsd.org/pipermail/svn-src-all/2020-August/201804.html

See D86397

Ah if you use _LIBUNWIND_USE_FRAME_HEADER_CACHE instead (i.e., a _ between FRAME and HEADER) it will match the workaround committed to FreeBSD.

Looks reasonable to me.

LGTM

LGTM, we acquired our strstr from musl

Fine with me

In D82786#2120605, @kevans wrote:

Sorry- the review is fine as-is. There is some nuance here, but it is better to just mark this unsupported for now (as you've done) and we (FreeBSD) can revisit later when all supported versions do not allow reading dirfds.

some nitpick comments. I'm not familiar with z/OS's APIs here so not qualified to fully review the change in getMainExecutable but seems reasonable

LGTM

LGTM

This LGTM.
I'm now adding support in FreeBSD, e.g. https://reviews.freebsd.org/rS361657

I will commit this shortly (and then merge the change into FreeBSD's copy).

Looks ok to me

In D77776#1981271, @jbeich wrote:

• Limit the scope to -stdlib

In D77776#1972543, @dim wrote:

the lowest supported version, which is currently 10

Where is this defined? Does someone build LLVM master on FreeBSD < 11.3?

reword

Ping.

In D73990#1858086, @MaskRay wrote:

It will be nice to include in the description what systems were not supported by hard coding 560, if such information can be obtained relatively easily.

Should have a test added

I think the default policy discussion might be better had on llvm-dev than a Phab review.

Shall we default to -mbranches-within-32B-boundaries if the specified -march= or -mtune= may be affected by the erratum?