[cfe-users] Feature request: include timing information in the analysis tool for each check
We're trying to integrate the a deep clang static analysis into our continuous integration setup, but one concern is that it takes quite a while to scan files. It would be great to see which commands are taking the longest. For example, the alpha clone check takes an extremely long time. ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Syncing up clang and clang-tools-extra with llvm for git
Hi, I'm hitting some segfault when I run dsymutil without any flags, but when I add "-update", it works. I'm curious about this flag, but i can't find any documentation. When it "updates", does that mean it needs an existing dSYM file to begin with? And what are the actual pros and cons of using this flag? FYI I'm trying to generate a dSYM for crash symbolication for an iOS app. Thanks, Michael ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Crash reporting for inline functions
Hi,
I've been playing around with a stack trace of inlined functions, e.g.:
void __attribute__((always_inline)) f1() {
f2();
}
void __attribute__((noinline)) f2() {
f3();
}
void __attribute__((always_inline)) f3() {
abort();
}
When I use various crash reporters, like PLCrashReporter and Crashlytics, I
don't see f1 or f3 in the stack trace, implying that inline functions
aren't included. However, when I cause the crash in the Xcode debugger, I
see the inline functions in the stack trace. Is there additional context
that Xcode would have, e.g. with symbols in the binary, that the crash
reporters with their dSYM files don't?
Thanks,
Michael
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] How can I hook malloc on iOS?
Hi, I'd like to hook malloc for an iOS app in order to use a custom allocator (jemalloc) that I have benchmarked and seen that it improves my app's performance. I know there must be a way to hook malloc, since the address sanitizer does it. Here are some possible routes: - Do whatever the address sanitizer does to wrap malloc. However, it's hard for me to figure out what's going on from the source code - Swap out the function pointers of the default malloc zone for my own, except that this is not safe - Use the zone manipulation in https://github.com/jemalloc/jemalloc/blob/dev/src/zone.c, except that this appears to have only been written with OS X in mind - Use CFAllocatorSetDefault, except that this seems to negate the speed wins that I see and will not cover cases where a library is using malloc rather than CFAllocatorAllocate - Use interposing to swap the functions early on, except that it doesn't seem to come soon enough to catch all mallocs, and the custom allocator crashes when it's told to free something allocated with the original malloc Does anyone have any ideas? Thanks, Michael ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] How does -forder-file-instrumentation work with respect to LTO?
Hi, I'm interested in using this flag, however I have a few questions. In Clang.cpp it states, "When ThinLTO is on, we need to pass these flags as linker flags and that will be handled outside of the compiler". When thin LTO is on, does this mean that it doesn't change the code but rather embeds information within the object file telling the linker to do the order file pass during its LTO phase? Are any flags required to be passed to the linker invocation for this? ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
