- User Since
- Dec 4 2015, 11:34 AM (102 w, 2 d)
Thu, Nov 16
Wed, Nov 15
Tue, Nov 14
Fri, Nov 10
An alternative could be to just disable the build of LSan on OS X < 10.9 (or even 10.11)
Because macOS changes quite a bit from version to version, we (or at least I) don't have strong plans to support LSan outside of 10.11+. Not sure what darwin used to store singleton kernel allocations before this page was introduced, but I assume that just not handling those allocations will lead to a ton of false positives. I'm inclined to let this fail on old versions unless there's someone willing to do the work to make sure they're properly supported. cc @kubamracek
Thu, Nov 9
Mon, Oct 23
Awesome, good to know. Thanks!
Sat, Oct 21
Oct 19 2017
On platforms where BOOL == signed char, is it actually undefined behavior (or is it just bad programming practice) to store a value other than 0 or 1 in your BOOL? I can't find any language specs suggesting that it is, and given that it's just a typedef for a signed char, I don't see why it would be.
Oct 16 2017
(for posterity, the build is not failing anymore with this patch committed)
Oct 10 2017
@qcolombet - Can you keep an eye on the internal apple builders and let me know if this doesn't fix them? I'll be out of the town the rest of the week though, so I probably won't be able to do much until Monday.
Improve warning messages
Used here: https://reviews.llvm.org/D38703
Clang change here: reviews.llvm.org/D38741
I'm going to be on vacation starting tomorrow (oct 11), and this seems like a pretty unoffensive change to me, so if I don't hear anything positive or negative by the end of the day, I'll commit this to fix the green bootstrapped builders.
I'll upload the clang host_cxx patch shortly, but this shouldn't be blocked on that (since it handles the undefined case).
Fairly certain that if this is 10.11-specific, it's either a leak in libxar, or a bug in LeakSanitizer. It doesn't appear to be a leak in objdump itself (particularly when looking at the stack, which has a dispatch_once call in it)
Oct 9 2017
Fix a couple python issues
Fixing a couple issues.
I got this failure to reproduce locally on my macOS 10.11 VM, but it's probably still worth disabling the leak checking on this test to fix the buildbots until I can diagnose the issue.
Oh interesting. I tried using PWD=/, but I didn't try actually cd-ing into that directory. I'll try that - thanks!
Looks good to me
I'm running into some issues with using a precompiled binary + object file here. For some reason, the debug info contains an absolute path to the object file instead of a relative path, so dsymutil will fail because it's looking for a path that doesn't exist (ie a path on my local machine). This is true even if I use -fdebug-compilation-dir (it updates the debug info in the IR, but doesn't change where dsymutil looks for the object file). I also tried -add_ast_path, which works as a hacky workaround because it will search the relative path in addition to the absolute path, but that seems like a bad solution.
Oct 6 2017
Use precompiled binary with IR as a comment to allow testing on linux
Move to x86 test dir
Delete copy constructor (which implicitly deletes move constructor), and
Oct 5 2017
They fail with:
while processing dwarf streamer init
error: : error: unable to get target for 'x86_64-apple-darwin', see --version and --triple.
Weirdly, appending .macho.x86_64 fixed the armv7/thumbv7 buildbots, but not aarch64. Will try to diagnose.
Don't call deallocation routines on null xar objects
Xar -> ScopedXar
I think that postfixing the binary name with ".macho.x86_64" will work, that seems to be what the other tests do, although I can't seem to find a lit config relating to that.
The test fails on non apple-x86_64 builders, reverted the patch for now
Maintain same behavior as apple's dsymutil
Prune some unneeded IR and debug info
I'm going to try to clean up the IR a bit
Oct 4 2017
Fix -no-output mode
Clean up comments
Asm->OutStreamer -> MS
Looks like they check in binaries as well. I'll upload a version with a binary for now, and I can swap it out if we decide we want to.
I have a test case working with an IR file, but it looks like most of the existing dsymutil tests just use an object file - should I do that here as well? (I don't think we get much value from using an IR file over an object file)