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 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 could possibly break the compiler. My only hypothesis is some sort of memory corruption. >> >> I will keep you posted. >> >> On Nov 14, 2013, at 9:22 PM, Kostya Serebryany <kcc at google.com> wrote: >> >>> 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 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 the changes or help debug the problem. >>>> >>>> How could this possibly affect your LTO build? >>>> The option is off by default. >>>> Do you have any details, logs, etc? >>>> >>>>> >>>>> —Bob >>>>> >>>>> On Nov 14, 2013, at 5:42 AM, Kostya Serebryany <kcc at google.com> wrote: >>>>> >>>>> Bob, Justin, >>>>> >>>>> I've just committed a poor man's coverage implementation that works with >>>>> asan. >>>>> http://llvm.org/viewvc/llvm-project?rev=194701&view=rev >>>>> http://llvm.org/viewvc/llvm-project?rev=194702&view=rev >>>>> It provides only function-level boolean coverage (i.e. no counters, just >>>>> "visited or not"), >>>>> but is very fast and very simple (no extra sections to the binary file, etc) >>>>> I've tried it for Chrome's content_shell (huge and heavy binary) and the >>>>> overhead >>>>> is negligible at both run-time and shutdown-time. >>>>> >>>>> We'll be evaluating this implementation and collecting usage stats. >>>>> Maybe we want to implement something simple like this in the Clang coverage. >>>>> >>>>> --kcc >>>>> >>>>> >>
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: > >> 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. >>> >>> I don’t have any other useful information at this point, and I share your puzzlement about how your changes could possibly break the compiler. My only hypothesis is some sort of memory corruption. >>> >>> I will keep you posted. >>> >>> On Nov 14, 2013, at 9:22 PM, Kostya Serebryany <kcc at google.com> wrote: >>> >>>> 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 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 the changes or help debug the problem. >>>>> >>>>> How could this possibly affect your LTO build? >>>>> The option is off by default. >>>>> Do you have any details, logs, etc? >>>>> >>>>>> >>>>>> —Bob >>>>>> >>>>>> On Nov 14, 2013, at 5:42 AM, Kostya Serebryany <kcc at google.com> wrote: >>>>>> >>>>>> Bob, Justin, >>>>>> >>>>>> I've just committed a poor man's coverage implementation that works with >>>>>> asan. >>>>>> http://llvm.org/viewvc/llvm-project?rev=194701&view=rev >>>>>> http://llvm.org/viewvc/llvm-project?rev=194702&view=rev >>>>>> It provides only function-level boolean coverage (i.e. no counters, just >>>>>> "visited or not"), >>>>>> but is very fast and very simple (no extra sections to the binary file, etc) >>>>>> I've tried it for Chrome's content_shell (huge and heavy binary) and the >>>>>> overhead >>>>>> is negligible at both run-time and shutdown-time. >>>>>> >>>>>> We'll be evaluating this implementation and collecting usage stats. >>>>>> Maybe we want to implement something simple like this in the Clang coverage. >>>>>> >>>>>> --kcc >>>>>> >>>>>> >>> >
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 any of the stages of the LTO build? > >> >> 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 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 could possibly break the compiler. My only hypothesis is some sort of memory corruption. >>>> >>>> I will keep you posted. >>>> >>>> On Nov 14, 2013, at 9:22 PM, Kostya Serebryany <kcc at google.com> wrote: >>>> >>>>> 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 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 the changes or help debug the problem. >>>>>> >>>>>> How could this possibly affect your LTO build? >>>>>> The option is off by default. >>>>>> Do you have any details, logs, etc? >>>>>> >>>>>>> >>>>>>> —Bob >>>>>>> >>>>>>> On Nov 14, 2013, at 5:42 AM, Kostya Serebryany <kcc at google.com> wrote: >>>>>>> >>>>>>> Bob, Justin, >>>>>>> >>>>>>> I've just committed a poor man's coverage implementation that works with >>>>>>> asan. >>>>>>> http://llvm.org/viewvc/llvm-project?rev=194701&view=rev >>>>>>> http://llvm.org/viewvc/llvm-project?rev=194702&view=rev >>>>>>> It provides only function-level boolean coverage (i.e. no counters, just >>>>>>> "visited or not"), >>>>>>> but is very fast and very simple (no extra sections to the binary file, etc) >>>>>>> I've tried it for Chrome's content_shell (huge and heavy binary) and the >>>>>>> overhead >>>>>>> is negligible at both run-time and shutdown-time. >>>>>>> >>>>>>> We'll be evaluating this implementation and collecting usage stats. >>>>>>> Maybe we want to implement something simple like this in the Clang coverage. >>>>>>> >>>>>>> --kcc >>>>>>> >>>>>>> >>>> >>