- User Since
- Sep 4 2015, 4:18 PM (214 w, 5 d)
Wed, Oct 9
Mon, Oct 7
Tue, Oct 1
Looks good to me but I'm not sure about the PATH changes.
Mon, Sep 30
Wed, Sep 18
Ping? I'm not sure if this is still required now that D63508 has been committed?
Looks good to me but I guess someone else should give the final approval.
Tue, Sep 17
Sep 3 2019
Aug 28 2019
Aug 27 2019
FreeBSD libc should be fixed instead.
Aug 26 2019
I believe I fixed this problem in https://reviews.llvm.org/rL369929
Aug 23 2019
Aug 22 2019
Ping? This breaks unit test when building with -DLLVM_INSTALL_BINUTILS_SYMLINKS=ON
LGTM except for one minor issue.
Aug 19 2019
Aug 9 2019
LGTM. This reduces the check-asan-dynamic test failures from 209 to 50 if I also apply the -pthread patch.
Aug 6 2019
Aug 3 2019
Jul 31 2019
Move the cast to dlsym() return value rather than the function pointer call
Used decltype now. Should be a bit shorter than the using declaration.
I still need the casts, otherwise the build fails when building the i368 RTSanitizerCommon.i386.dir/sanitizer_linux.cc.o:
/exports/users/alr48/sources/upstream-llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:786:57: error: cannot initialize a parameter of type 'size_t *' (aka 'unsigned int *') with an lvalue of type '__sanitizer::uptr *' (aka 'unsigned long *')
Jul 30 2019
Jul 29 2019
Jul 28 2019
Remove mention of FreeBSD from comment
Jul 27 2019
Jul 26 2019
Always use xcrun
Use the more portable dlsym() instead of dlfunc()
- Address review feedback
- Remove XFAIL: freebsd from another test that now passes
Remove freebsd XFAIL from two tests that pass with this change
Jul 25 2019
Jul 24 2019
Yes I actually mean D65221
This broke ASAN on FreeBSD (same for the MSAN change). When loading static thread_local struct tsd_key key this is done using __tls_get_addr. The interceptor for __tls_get_addr then calls GetCurrentThread which calls AsanTSDGet which again calls __tls_get_addr.
If I remove the || SANITIZER_FREEBSD it works fine (at least on FreeBSD 11.2).
Jul 12 2019
Thanks for your work on this! Looking forward to be able to use these new features the next time I update our fork.
Jul 9 2019
This will cause big merge conflicts the next time I update our CHERI fork. However, the change itself looks good to me so I have no objections.
Jul 5 2019
Jul 3 2019
Jun 30 2019
Jun 20 2019
Jun 12 2019
Jun 11 2019
Looks good to me. Just two minor comments:
This looks good to me. However, I think the name SymbolicRel does not make it immediately obvious to me it should be used for. Maybe add a comment to the member?
May 22 2019
May 9 2019
I implemented the same thing for the CHERI fork of lld since I added some new warning that could in certain cases be emitted many times but are not necessarily a real problem.
May 8 2019
May 2 2019
Apr 24 2019
Apr 16 2019
Thanks for fixing this! LGTM
Apr 11 2019
Mar 29 2019
LGTM once the tempfile is deleted.
Mar 28 2019
Mar 26 2019
Mar 21 2019
The value of getAddend<ELFT>(Rel); now only seems to be in Ref.getRawDataRefImpl().p now. Shouldn't the rel case also be adding the implicit addend? I'm not sure I'm reading the code currently but it looks to me like REL no longer gets the addend added.