similar to: [LLVMdev] asan coverage

On Feb 12, 2014, at 10:31 AM, Kostya Serebryany <kcc at google.com> wrote: > Hi, > > Justin is making nice commits for llvm-cov, so I thought we may continue this discussion now. > The quick-and-dirty implementation of coverage (in asan) is getting some early users and they seem to be happy. > AsanCoverage allows to collect per-function or per-basic-block coverage

On Feb 12, 2014, at 11:43 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Thu, Feb 13, 2014 at 11:10 AM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Feb 12, 2014, at 10:31 AM, Kostya Serebryany <kcc at google.com> wrote: > >> Hi, >> >> Justin is making nice commits for llvm-cov, so I thought we may continue this

On Fri, Nov 15, 2013 at 7:26 AM, Bob Wilson <bob.wilson at apple.com> wrote: > Hi Kostya, > > Thanks for the heads-up on this. I haven’t had a chance to look into the > details yet, but it looks like these patches may be breaking our > bootstrapped LTO build. Our buildbots have been failing all day, and we’re > still trying to figure out the problem. I’m going to

I’m waiting to see if this fixes the buildbots. Unfortunately, because they were failing all day, there are a bunch of other regressions that have come up, and I’m still working through them. It takes quite a while to run a bootstrapped LTO clang build, so it will take a while longer. I don’t have any other useful information at this point, and I share your puzzlement about how your changes

The bit code file produced by the stage 1 compiler for one of the files in the clang driver is corrupt and causes the linker for stage 2 to crash. On Nov 14, 2013, at 10:13 PM, Kostya Serebryany <kcc at google.com> wrote: > What are the symptoms? > > On Fri, Nov 15, 2013 at 9:37 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> I’m waiting to see if this fixes the

No, not that I am aware of. On Nov 14, 2013, at 10:15 PM, Kostya Serebryany <kcc at google.com> wrote: > On Fri, Nov 15, 2013 at 10:14 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> The bit code file produced by the stage 1 compiler for one of the files in the clang driver is corrupt and causes the linker for stage 2 to crash. > > Is AddressSanitizer involved in

Also, when are you planing to "reapply the changes or help debug"? On Fri, Nov 15, 2013 at 9:15 AM, Kostya Serebryany <kcc at google.com> wrote: > On Fri, Nov 15, 2013 at 7:26 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> Hi Kostya, >> >> Thanks for the heads-up on this. I haven’t had a chance to look into the >> details yet, but it looks

Hi Kostya, Thanks for the heads-up on this. I haven’t had a chance to look into the details yet, but it looks like these patches may be breaking our bootstrapped LTO build. Our buildbots have been failing all day, and we’re still trying to figure out the problem. I’m going to speculatively revert those changes, since they were the only patches on the buildbot blame list. I will either reapply

I don’t know yet, but I will let you know as soon as I can. On Nov 14, 2013, at 10:18 PM, Kostya Serebryany <kcc at google.com> wrote: > On Fri, Nov 15, 2013 at 10:16 AM, Bob Wilson <bob.wilson at apple.com> wrote: >> No, not that I am aware of. > > So, if my commits did indeed trigger the failures it could be > something like binary size change that caused

What are the symptoms? On Fri, Nov 15, 2013 at 9:37 AM, Bob Wilson <bob.wilson at apple.com> wrote: > I’m waiting to see if this fixes the buildbots. Unfortunately, because they were failing all day, there are a bunch of other regressions that have come up, and I’m still working through them. It takes quite a while to run a bootstrapped LTO clang build, so it will take a while longer.

On Fri, Nov 15, 2013 at 10:14 AM, Bob Wilson <bob.wilson at apple.com> wrote: > The bit code file produced by the stage 1 compiler for one of the files in the clang driver is corrupt and causes the linker for stage 2 to crash. Is AddressSanitizer involved in any of the stages of the LTO build? > > On Nov 14, 2013, at 10:13 PM, Kostya Serebryany <kcc at google.com> wrote:

Yes. I'm seeing this as well and it predates Kostya's change. Shows up as memory corruption or double free on Linux. On Nov 14, 2013 10:46 PM, "Alexey Samsonov" <samsonov at google.com> wrote: > FYI I've seen what looked like a memory corruption in (private) Clang > bootstrap process long before Kostya's changes were submitted. I hope I'll > have the

On Fri, Nov 15, 2013 at 10:16 AM, Bob Wilson <bob.wilson at apple.com> wrote: > No, not that I am aware of. So, if my commits did indeed trigger the failures it could be something like binary size change that caused different code alignment or some such and which triggered a latent memory bug somewhere else. It's already late evening for you now. Will you have a chance to reapply

FYI I've seen what looked like a memory corruption in (private) Clang bootstrap process long before Kostya's changes were submitted. I hope I'll have the chance to investigate it soon. On Fri, Nov 15, 2013 at 10:20 AM, Bob Wilson <bob.wilson at apple.com> wrote: > I don’t know yet, but I will let you know as soon as I can. > > On Nov 14, 2013, at 10:18 PM, Kostya

I was able to successfully build with r194701, so I have reapplied that along with the compiler-rt changes. Somehow we need to get to the bottom of the problem. If you can reproduce it, please help!! On Nov 14, 2013, at 11:01 PM, Eric Christopher <echristo at gmail.com> wrote: > Yes. I'm seeing this as well and it predates Kostya's change. Shows up as memory corruption or

On Tue, Feb 18, 2014 at 10:15 PM, Bob Wilson <bob.wilson at apple.com> wrote: > Our instrumentation code is basically done now, so you can try it out and > compare the performance. Just build with -finstr-profile-generate. > Is this in trunk? clang-3.5: error: unknown argument: '-finstr-profile-generate' --kcc > You may want to hack the compiler-rt code in

Regarding performance, I've made a simple coverage with counters and compared it with AsanCoverage. AsanCoverage produces code like this: mov 0xe86cce(%rip),%al test %al,%al je 48b4a0 # to call __sanitizer_cov ... callq 4715b0 <__sanitizer_cov> A simple counter-based thing (which just increments counters and does nothing else useful) produces this: incq 0xe719c6(%rip) The

On Feb 17, 2014, at 5:13 AM, Kostya Serebryany <kcc at google.com> wrote: > Then my question: will there be any objection if I disentangle AsanCoverage from ASan and make it a separate LLVM phase with the proper clang driver support? > Or it will be an unwelcome competition with the planned clang coverage? I don’t view it as a competition, but assuming that we both succeed in our

I've built chromium with " -fprofile-instr-generate -fsanitize=address" -- the performance looks good! The file format from r198638 is indeed rudimentary. Do you already know how the real output format will look like? Just to summarize what I think is important: - minimal size on disk, minimal amount of files - minimal i/o while writing to disk, no lockf or some such -

Hello, I have few questions about coverage. Is there any user-facing documentation for clang's "-coverage" flag? The coverage instrumentation seems to happen before asan, and so if asan is also enabled asan will instrument accesses to @__llvm_gcov_ctr. This is undesirable and so we'd like to skip these accesses. Looks like GEP around @__llvm_gcov_ctr have special metadata