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

The FreeBSD build bot was down for a little over a week due to an IP address issue, but is back now: http://lab.llvm.org:8011/builders/lldb-amd64-ninja-freebsd11

In D50297#1236972, @ruiu wrote:

In theory this change shouldn't affect the amount of memory used by an application

Agreed - when I submitted it I thought it might be uncommon but worth supporting, but the evidence Mark found suggests it is a single-purpose feature that is not relevant to the platforms lld supports.

Thanks for finding that Mark - based on that IMO this feature is not worth supporting.

keep flags in order

Reuse existing FLAGS: test

See also https://reviews.freebsd.org/D17172 for a lld 6 version intended for commit to FreeBSD's in-tree lld.

@ruiu what do you suggest as the next step here?

LGTM. I made the same change in FreeBSD r336745.

FWIW I don't have a strong opinion on | vs newline to separate aliases, but if we are going to go with the newline -compact and .Pp approach I'd suggest making that change as a separate commit first so that the actual content changes here are easier to see/review.

For reference I had a discussion on markup for option aliases with Ingo Schwarze and he wrote:

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