In D50920#1165848, @kib wrote:

Consider increasing RTLD_STATIC_TLS_EXTRA, we now use 16 bytes there unconditionally.

Embed TAILQ_ENTRY in TLS block as if it were TLS data

Update comment

Rebased

In D50717#1157838, @imp wrote:

So why is this desirable?

In D50716#1158047, @kib wrote:

You need at least sys/types.h there as well.

Move endif

Trim and sort CFLAGS

In D50683#1157180, @markj wrote:

In D50683#1157061, @jrtc27 wrote:

What if there is no symbol (which presumably shows up as off != 0, using whatever symbol happens to be before it)? Or it's in another file? Those are legitimate cases (the former in particular, that's for when the implementation is static, and the latter is weird but there's no reason you can't do it).

If there's no symbol, what should we do? I don't think it's really correct to keep passing the resolver symbol's size, so should we just set it to 0 instead? In practice this case currently doesn't arise AFAICT, and so I'm rather inclined to signal the failure to the consumer.

What if there is no symbol (which presumably shows up as off != 0, using whatever symbol happens to be before it)? Or it's in another file? Those are legitimate cases (the former in particular, that's for when the implementation is static, and the latter is weird but there's no reason you can't do it).

As mentioned on IRC but summarised here for reference: do we want to support PKGCONFBRANCH=latest being set in a user's src.conf on release branches? 0b18e008ccf74ee87d38ca16c9c4d9bb0b174bec deliberately made this an overridable variable, and so it we want to preserve that we probably should have a latest-release file too.

Extend existing comment to note different implementation to NetBSD

In D50563#1154663, @kib wrote:

Indeed this is not how things are supposed to work. At least on x86, this is how things are. There are vendor libs linked with static TLS model, which happens to be dynamically loaded, and people really want that to work. The libs cannot be recompiled (they come from nvidia).

If you want to keep risc-v "pure", it is up to you.

I've gone digging and this looks like confusion importing NetBSD's code. This was applying https://github.com/NetBSD/src/commit/cc08a85a2529815b95799c6500b40a2c596c0c93 to our tree, just as 91880e07f605edb90339685bc934699a4344de3b was https://github.com/NetBSD/src/commit/3caa8dc7351c8383b2c3832b2610624b347e9065. The key point is that FreeBSD's tlsoffset is always relative to the TCB, whereas for Variant I TLS on NetBSD it's relative to the end of the TCB. So the original code was wrong for NetBSD but right for FreeBSD, and the updated code fixed it for NetBSD but broke FreeBSD by importing it. Will update the commit message with a properly-written summary tomorrow.

NB: I do intend to do that cleanup, just not tonight

In D50459#1151997, @emaste wrote:

would it not be even faster, and sidestep the issue entirely, if we just used bsdtar's -J flag

Good point, although that might be GNU tar on other systems? If so -J should be fine but is --options xz:threads=0 handled?

macOS's /bin/sh is governed by /private/var/select/sh. On my system it's /bin/bash and supposedly new macOS installs will default it to /bin/dash (at least according to tools/build/Makefile, which links /bin/bash into the tmp path as sh) so will hit the same issue. Is there a reason to use the pipe though; would it not be even faster, and sidestep the issue entirely, if we just used bsdtar's -J flag? (You can set xz:compression-level and xz:threads on the command line)

Unhook from build and clean up