In D41821#1152337, @atanasyan wrote:

I'm going to implement both parts of the plan.

In D31528#1114868, @atanasyan wrote:

Ping?

@ruiu could I use a post-commit review option in that case?

In D46690#1094394, @grimar wrote:

After the second look, I think it is ok to add check here that we still keep non-a section and keep its SHT_NOTE flag for safety though. I'll update the patch.

note-noalloc2.s is close to my original test, I think that's reasonable.

1. what is the content of .debug-ghc-link-info? If the section contains an optional, human-readable string, they might have just used .comment instead.

Committed to FreeBSD in r333401

Yeah, @espindola was added by a Herald rule.

@arichardson @dim I'm also looking for approval to commit the change to FreeBSD (perhaps in advance of committing upstream), with a bump of the FreeBSD-specific version to LLD_REVISION_STRING "326565-1200002" - I might as well solicit that via this review.

Nice :)

Do we know why pthread_{get,set}specific fails now? And would it make sense to use tls more broadly (not just on FreeBSD)?

Happy belated birthday Multi-GOT patch

LGTM

In D43751#1031350, @mgorny wrote:

Thanks for the review. As for the -Wl,-z,origin part, I'd rather leave that alone unless we have a clear indication that either it is not necessary for any of the supported FreeBSD and DragonFly BSD versions, or that it can be passed unconditionally without breaking any of the supported systems (and which linkers accept it).

LGTM for FreeBSD

In D43751#1030947, @krytarowski wrote:

ld(1) might accept -z origin, but why do we want it for other OSes? I don't see it used in the NetBSD dynamic ELF loader. DF_ORIGIN is just defined but not used by anything.

In D43751#1027263, @krytarowski wrote:

Uconditionally for all Unices? I don't think so.

LGTM from the FreeBSD perspective

In D43643#1016430, @efriedma wrote:

Is the pass intentionally named "Sceptre"? That's amusing, but kind of confusing.

In D42516#1015414, @jakehehrlich wrote:

You can download the zip file that I'm using here: https://drive.google.com/file/d/1u6W1mUHkFBPsLzEV4u50M_BeiPKMyipM/view?usp=sharing

In D42516#1014317, @jhenderson wrote:

One other point - it would be good to compare the performance of llvm-objcopy to GNU objcopy in this case, and if we're a lot worse, run a profiler at some point to identify what we're doing that makes things worse.

In FreeBSD libpthread.so is a symlink to libthr; -pthread and -lpthread should both work.

This LGTM

Thanks, I'll commit this later today. Not sure how I ended up with 01 instead of O1 but have fixed those locally.

PDF version of current version:

• more feedback from review
• incorporated doc updates for -z from https://reviews.freebsd.org/D14220

PDF rendered version of the man page:

Incorporate review feedback

• Update copyright and license statement
• Remove internal -full-shutdown option

In D31528#987543, @atanasyan wrote:

We have a chance to celebrate the first anniversary of this patch in a couple of months. Is it possible to escape this dubious holiday?

Seems fine to me

The title is more correctly "non-Apple hosts"? I.e., building on FreeBSD will also use llvm-objcopy.

Is there any plan (or willingness?) to backport this further, to 4.0.0 and even 3.4.1?

With this patch applied Kostik's original testcase passes.

LGTM

The original FreeBSD test case (a 'hello world' linked with lld -znotext) works with this change applied.

Conflicts after rL321430. I tried a straightforward rebase (moving the if ((S.Flags & SHF_WRITE) || !Config->ZText) block below if (Sym.isUndefWeak()) but test/ELF/retain-und.s (from rL293093) fails.

LGTM.

This LGTM, I had a similar change in my repo while trying to fix PR35720.

I can confirm this fixes the reduced test case, but the 'hello world' test on FreeBSD still fails, now with:

Ping?

FWIW our standard readelf in FreeBSD comes from the ELF Tool Chain project and doesn't have the warning. It's only when the GNU readelf package is installed that we'd encounter this.

This LGTM (but @ruiu or @grimar please review as well).

From e-mail followup @dim linked against libc linked with pre-patch lld.