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.

In D58102#1422441, @hjl.tools wrote:

We are using a special CET SDV for CET enabling. We have been enabling CET in Fedora piece by piece by adding -fcf-protection to CFLAGS.

In D58102#1422340, @xiangzhangllvm wrote:

H.J. have enable the CET in GNU-toolchain and rebuild/rewrite the related libs/linux-kernal, his team are testing it for at last one year.

@xiangzhangllvm, a question for you not directly related to the patch but I suspect you might be best suited to find an answer: how do we test CET support today? We started trying to add CET to FreeBSD some time ago but have no way to test any work that we do.

In D58102#1411701, @fweimer wrote:

How does lld handle the non-executable stack flag? From a developer point of view, the CET processing is supposed to be very similar.

@dim

In D57371#1390001, @ruiu wrote:

Ed,

Did -z ifunc-noplt work well for FreeBSD kernel? If it works well, maybe we should merge it to the mainline lld tree?

In D57749#1385666, @joerg wrote:

The description is certainly not right. IE can be used from dlopen'd objects without problems as long as there is still reserved space around and the data is not initialized non-trivially or the dynamic linker is willing to fix up all threads. The point of the flag is to allow the dynamic linker to make a quick decision without having to scan the relocation table first. A classic user of this was libGL. It also applies to many platforms, not just i386. As such, please update the description before any commit.

In D33041#1382751, @grimar wrote:

In D33041#1382592, @emaste wrote:

FreeBSD patch adding initial exec TLS mode for dynamically loaded shared objects: https://reviews.freebsd.org/D19072. Can we revisit this lld patch?

I'll take a look tomorrow.

FreeBSD patch adding initial exec TLS mode for dynamically loaded shared objects: https://reviews.freebsd.org/D19072. Can we revisit this lld patch?

There is a list of 140-150 unsafe (LLD_UNSAFE) packages with LLD.

I think the arch-change (switching from a whitelist to a MIPS blacklist) is reasonable. What is the motivation for dropping DT_HASH, just binary size reduction?

Can I go ahead with this version as a starting point?

• fix warnings from mandoc -Tlint and/or igor
• remove options that should not be listed

This is fine for me (from FreeBSD's perspective), but I suspect some people (on operating systems without ifuncs in libc) may be surprised by having a(n empty) .rela.plt in all of their statically linked binaries.

I have an interim copy in FreeBSD and am updating it based on the feedback here; I'll update this review shortly.

Additional comment that wasn't submitted while reviews.llvm.org was down on Friday: I started working on this as it's needed for us to switch from GNU objdump to llvm-objdump in FreeBSD (FreeBSD PR229046).

Review feedback

I think this is reasonable.

Perhaps someone else can review?

In D54864#1307053, @Higuoxing wrote:

lgtm, but seems that some hidden/alias options are not listed here (I could help add them). I am not expert in this area, so I will leave the decision to @kristina

Confirmed this fixes my bug.

I think that the inconsistency of linkers behavior shown above shows that LLD behavior is not incorrect. It is different. But we never tried to be fully bug compatible with bfd/gold. First of all the problem is caused by a weak assumption in the linker script, which assumes that orphans are placed at the particular place before the assignment command, and my feeling it should be fixed.

I backported the change to lld 6.0 currently in FreeBSD-HEAD and it has the expected behaviour, but for my test case I think sh_info should reference .got.plt not .plt - note the address marked with ######## below.

This change looks good to me; testing it out in the FreeBSD tree now.

This change LGTM.

Looks good to me

For SHT_REL and SHT_RELA, sh_link references the associated symbol table and sh_info the "section to which the relocation applies."

I don't think you can fix the issue by recompiling it without -fPIC

I would think a fix would be compiling with -fPIC.