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.

I successfully linked all of FreeBSD/amd64 with LLD head + this patch.

Spoke too soon - buildworld is actually failing elsewhere now, with my backported patch in lld.

/usr/obj/usr/home/emaste/src/freebsd/amd64.amd64/tmp/usr/bin/ld: error: relocation R_X86_64_PLT32 cannot refer to absolute symbol: __tls_get_addr
>>> defined in <internal>
>>> referenced by runetype.h:98 (/usr/obj/usr/home/emaste/src/freebsd/amd64.amd64/tmp/usr/include/runetype.h:98)
>>>               xlat16_iconv.pico:(kiconv_xlat16_open)

I probably have an error in my backport attempt though, this other library (lib/libkiconv) linked succesfully with lld head + this patch.

I tested this patch against lld head and confirm it resolves the issue via my reproducer. I also backported it to lld 5.0.1 (the version in FreeBSD HEAD) , rebuilt, and confirm that sbrk() is functional.

Thanks for including the steps you used to effect the mechanical change! Having maintained long-lived derived branches of open source projects in the past I've found that sort of thing very helpful.

In D38900#897304, @krytarowski wrote:

@joerg might have insight on ppc, sparc64, arm on NetBSD.

In D38142#882374, @bkoropoff wrote:

Since I'm a first-time contributor, I definitely don't have commit privileges. Should I apply for them, or is someone else supposed to commit this for me?

I realized I don't have my LLVM SVN creds on my laptop, so will commit this when I return home in a couple of days if it's still not done.

In D38142#882374, @bkoropoff wrote:

Since I'm a first-time contributor, I definitely don't have commit privileges. Should I apply for them, or is someone else supposed to commit this for me?

Very small nit noticed on another look: there are couple of instances of Mib that should be MiB