- User Since
- Jan 17 2017, 2:21 PM (221 w, 5 d)
Thu, Apr 15
Will commit this version on Monday unless anyone has further comments.
Rebase after D29528
Wed, Apr 14
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
Tue, Apr 13
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.
Sat, Apr 10
ping? Can we drop the immutable setting so that arc diff adds the Differential Revision: metadata to commit messages automatically?
Fri, Apr 9
I had a similar patch locally using =strict, but it seems like maytrap should be sufficient.
The new version uses COMPILER_FEATURES instead.
bmake: "/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: "/Users/alex/cheri/cheribsd/share/mk/bsd.compiler.mk" line 254: COMPILER_TYPE=clang bmake: "/Users/alex/cheri/cheribsd/share/mk/bsd.compiler.mk" line 255: COMPILER_VERSION=120000 bmake: "/Users/alex/cheri/cheribsd/share/mk/bsd.compiler.mk" line 256: X_COMPILER_FEATURES=c++11 c++14 c++17 retpoline init-all bmake: "/Users/alex/cheri/cheribsd/share/mk/bsd.compiler.mk" line 257: X_COMPILER_TYPE=clang bmake: "/Users/alex/cheri/cheribsd/share/mk/bsd.compiler.mk" line 258: X_COMPILER_VERSION=130000
Use COMPILER_FEATURES instead
Update some pre-generated files
Thu, Apr 8
@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
Wed, Apr 7
Mon, Apr 5
Thu, Apr 1
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.
Add a local implementation of memcpy/memset instead.
With the latest version I get the following error :
bmake: "/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: 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
Wed, Mar 31
Sorry didn't see this revision. I chose a slightly different approach in D29495
Tue, Mar 30
add missed case