ping?

ping?

ping?

Will commit this version on Monday unless anyone has further comments.

ping?

Rebase after D29528

Looks like the warning is not triggered for x86, only other architectures. That indicates that the pragmas might actually be implemented now.
Should I restrict the -Wno-error to non-x86?

• Use __XSTRING

I saw this building CheriBSD, and I think it affected almost all architectures.

re-generate bootstrap files

I think arcanist might not like numeric-only callsigns? I can't figure out what the correct value should be.

rebase

ping? Can we drop the immutable setting so that arc diff adds the Differential Revision: metadata to commit messages automatically?

I had a similar patch locally using =strict, but it seems like maytrap should be sufficient.

The new version uses COMPILER_FEATURES instead.

bmake[2]: "/Users/alex/cheri/cheribsd/share/mk/bsd.compiler.mk" line 253: COMPILER_FEATURES=apple-clang c++11 c++14 c++17 retpoline init-all
bmake[2]: "/Users/alex/cheri/cheribsd/share/mk/bsd.compiler.mk" line 254: COMPILER_TYPE=clang
bmake[2]: "/Users/alex/cheri/cheribsd/share/mk/bsd.compiler.mk" line 255: COMPILER_VERSION=120000
bmake[2]: "/Users/alex/cheri/cheribsd/share/mk/bsd.compiler.mk" line 256: X_COMPILER_FEATURES=c++11 c++14 c++17 retpoline init-all
bmake[2]: "/Users/alex/cheri/cheribsd/share/mk/bsd.compiler.mk" line 257: X_COMPILER_TYPE=clang
bmake[2]: "/Users/alex/cheri/cheribsd/share/mk/bsd.compiler.mk" line 258: X_COMPILER_VERSION=130000

Use COMPILER_FEATURES instead

Update some pre-generated files

@sjg Should I send this patch somewhere else to get it upstreamed, or is posting it here sufficient?

Seems reasonable to me (unless we want to support TLS inside RTLD but that seems like it would require more work).

Should they also be cleared in exec_setregs()? Or do we expect to keep them if they are changed after fork()?

Abandoning in favour of D29159

Actually I think this solution is probably better than D29495. I just encountered some annoying errors where depending on ifdefs the set can be either empty or non-empty. Probably better to just always declare them weak.

Have to handle the kernel module case, so we do actually need the __GLOBL().

• tinderbox fixes

drop __GLOBL()

In D29323#658959, @walker.aj325_gmail.com wrote:

acl_get_fd(fd): Invalid argument
futimens(fd): Invalid argument
extattr_set_fd(fd): Invalid argument

Okay. These now fail as expected. errno is EINVAL rather than EBADF. In case of futimens() Linux fails with EBADF.

Sorry, I probably didn't explain the problem correctly. I will do some more debugging next week to narrow down the exact cause of this problem.

Will try to silence the false-positives inside TSan instead.

The problem in TSan is that __interceptor_memcpy (dst=0x7fffdf9f97c0, src=0x7fffdf9f9c00, size=880) is called from a signal handler context, but TSan doesn't know about that and this corrupts the internal state. If I instead intercept __sys_sigaction to make TSan receive the signals and forward them to libthr, this causes even worse internal consistency issues in all sanitizer runtimes. Simply avoiding that one interposable call makes the TSan runtime happy again.

In D28536#662153, @kib wrote:

No, I object against this kind of ugliness. mem* functions are thread- and async-signal-safe. If something cannot intercept them without satisfying the requirements, that something is buggy.

Please just inline memcpy in single place (?) where it is needed. Or provide the local copy for it, again in the place where it is needed, perhaps naming it differently.

Add a local implementation of memcpy/memset instead.

In D29535#662078, @jrtc27 wrote:

intptr_t isn't sufficient for hybrid CHERI though, so we'd still need the diff to make it intcap_t downstream...

In D29536#662074, @jrtc27 wrote:

Would (u)intptr_t make more sense so it's faster on CHERI? Doesn't make a difference upstream but does to us.

With the latest version I get the following error :

bmake[5]: "/Users/alex/cheri/freebsd/share/mk/bsd.dep.mk" line 203: "$OBJS absolute path not allowed: /Users/alex/cheri/build/freebsd-amd64-build/Users/alex/cheri/freebsd/amd64.amd64/stand/i386/btx/lib/crt0.o.  If this is intended, add them to _ABSOLUTE_PATH_OBJS to silence this error or define _ALLOW_ABSOLUTE_OBJ_PATH to disable this diagnostic."
bmake[5]: stopped in /Users/alex/cheri/freebsd/stand/i386/loader_4th

To avoid this I changed loader/Makefile.

• Move to shared file
• add opt-out mechanism
• Use it to fix loader build

Will commit this on Monday unless D28886 is committed first.

I've posted D29528 to get CI green again and allow for more time for this patch to be reviewed.

Cherry-pick upstreamed commit instead

Sorry didn't see this revision. I chose a slightly different approach in D29495

add missed case

switch order