- User Since
- Aug 21 2015, 4:29 PM (204 w, 2 d)
Thu, Jul 18
@daltenty Other than the minor nit, LGTM.
Wed, Jul 17
Thu, Jul 11
Tue, Jul 9
Fri, Jul 5
@AlexeySachkov LGTM provided the lit tests continue to pass.
@daltenty The "This removes our dependency on psutil." text sounds broader than it actually is. Looking at the implementation the removal of the dependency is only for AIX. All other platforms still depends on the psutil module. I think the commit message should be made clearer on this point.
Thu, Jun 27
Tue, Jun 25
Mon, Jun 24
@vitalybuka Sorry. I didn't see this before.
Jun 21 2019
@hans @thakis Commenting out find_darwin_sdk_dir(DARWIN_iossim_SYSROOT iphonesimulator) was enough for me to reproduce the issue. There's a bug in some existing CMake code I wrote. The code for UBSan test code assumes that if COMPILER_RT_ENABLE_IOS is true that the toolchain can build for iOS and the iOS simulator. This isn't true if one or more of the SDKs are missing. I've written a fix for this and I'll submit a patch for review soon.
But somehow it was still able to produce an i386 version of libclang_rt.asan_iossim_dynamic.dylib before your change.
Jun 20 2019
Jun 17 2019
@vitalybuka Sorry I forgot about this. I tried to make the test to work in a POSIX use case and I can't make it work. The problem is that when I use %M with stack_trace_format the module name gets stripped (i.e. an absolute path to the binary just becomes the file name of the binary) due to the call to StripModuleName(). This results in us not being able to symbolicate the report from the python script because we don't have the absolute path to the binaries we need to access to perform symbolication.
@juliehockett Sorry I completely dropped the ball here and forgot to land this. I've rebased and committed the change. @thakis I noticed I had a merge conflict with your change. Hopefully this hasn't broken anything for you.
Jun 11 2019
Apr 28 2019
@juliehockett @phosek This is a new version of https://reviews.llvm.org/D58578 . Would you be able to test it in your set up? I'd prefer to have the confidence of knowing it doesn't break your set up before landing this.
Apr 27 2019
Sure -- to clarify, it's not a test failure, it's a build one. The error was triggered during the CMake configuration step for host runtimes, where we have OSX supported arches: x86_64 only. test/tsan/CMakeLists.txt:78 now calls into the new function on the arm64 case, which down the line triggers a CMake assert that arm64 is in the list of supported arches when it isn't.
Seems like prior to this change, the lit tests were being configured without doing any checks on that list of supported arches. I'm not as familiar with how this code is set up, so I can't really say if it's a problem with this patch or if this patch is exposing another bug. Thanks for taking a look!
To clarify, this is failing when building runtimes for Darwin so shouldn't be Fuchsia specific, but it could be affected by some of the Clang defaults we set in our CMake build. We use lld as the default linker for Fuchsia but not for Darwin where use the system linker.
Apr 26 2019
Sorry about this. I'll revert the patch now and I'll take a look at re-landing it when time permits.
No real update, just for fixing up commit message on my local machine.
Apr 24 2019
Apr 23 2019
Apr 18 2019
Looks like the build broke some bots (http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-android/builds/21212). It seems the code doesn't work properly in some really old versions of Python 2. I've managed to reproduce the issue using Python 2.7.6 and I've landed a fix https://reviews.llvm.org/rL358682
Apr 17 2019
Apr 16 2019
Apr 11 2019
Apr 10 2019
- Use cstdlib include instead of stdlib.h
- Remove unused assert.h include
- Use cstdlib header rather than stdlib.h
- Drop unused assert.h
Use cstdlib rather than stdlib.h