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?

Use elf_aux_info() if we can

See https://bugs.freebsd.org/241932

Out of curiosity what workflow leads to BOMs in linker scripts?

I was under the impression that -P was supported on FreeBSD.

Is this using the system nm? ELF Tool Chain nm does not (currently) support the -P flag.

OK with me

For reference libcxxrt comes from here: https://github.com/libcxxrt/libcxxrt

In D60748#1499756, @dim wrote:

Please also exclude FreeBSD from these changes, since we care a lot about backwards compatibility, and specifically about alignment requirements. (We have run into many issues in our ports collection where upstream assumes everything is 16-byte aligned on i386, which is *NOT* ABI compliant.)

This is fine with me as a little simplification and avoid an extra syscall.

From sysctl_kern_proc_pathname:

error = vn_fullpath(req->td, vp, &retbuf, &freebuf);
vrele(vp);
if (error)
        return (error);
error = SYSCTL_OUT(req, retbuf, strlen(retbuf) + 1);

and in vn_fullpath:

buf = malloc(MAXPATHLEN, M_TEMP, M_WAITOK);

LGTM from the FreeBSD perspective.

Ping

• rebase
• also change __addtf3 return type

Correct typo, update tests

It turns out __LP64__ is wrong anyway, see D66758, so I intend to commit this first with no functional change and then follow up with D66758.

FreeBSD references:
https://reviews.freebsd.org/D17930
https://reviews.freebsd.org/rS343429

And moved to CodeGen in rL339397

In D14700#1597957, @emaste wrote:

@brooks @arichardson is this something we want to revisit?

In D65430#1605980, @peter.smith wrote:

My understanding is that many developers use makefile/ninja generation systems such as cmake rather than hand-write the file themselves. As such would this get much use unless it was integrated into these generators? May be worth approaching them to see if they have any requirements/observations about the option?

@brooks @arichardson is this something we want to revisit?

OK, I will try to check if it still applies cleanly and commit soon

@brooks, @arichardson do we still want to pursue this?

I've created D62862 which is independent of X86/AArch64.

In D50294#1246980, @MaskRay wrote:

In D50294#1245454, @emaste wrote:

I'm using this change: https://github.com/emaste/freebsd/commit/1c3deab6d518feb1a7e88de5b342a139e4022a21

In FreeBSD 12 and later we use Clang, lld, and ELF Tool Chain. (We still have gas and objdump from the outdated binutils 2.17.50.)

Will you upstream this commit (I can abandon this one)? I created this revision because I was learning clangDriver... I had a vague and probably incorrect impression that some folks said kgdb or dtrace or whatever might not support DWARF 3 or 4.

LGTM. I much prefer only - short and -- long options, except for lld where unfortunately there's a precedent of accepting both.