[compiler-rt] r362676 - [Profile]: Add runtime interface to specify file handle for profile data.

Hans Wennborg via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 13 00:14:29 PDT 2019


To build stage 1, I'm using gcc (Debian 7.3.0-18) 7.3.0

I'll send the output of env in a separate email, but I expect it's a
similar Linux workstation environment as yours.

On Wed, Jun 12, 2019 at 11:21 PM Sajjad Mirza <sajjadm at google.com> wrote:
>
> What compiler are you using to compile stage 1?
>
> I get a different failure during stage 2:
>
> [1864/2833] Building DiagnosticParseKinds.inc...
> FAILED: tools/clang/include/clang/Basic/DiagnosticParseKinds.inc
> cd /local/ssd1/sajjadm/llvm-project/stage2 && /local/ssd1/sajjadm/llvm-project/stage2/bin/clang-tblgen -gen-clang-diags-defs -clang-component=Parse -I /local/ssd1/sajjadm/llvm-project/clang/include/clang/Basic -I /local/ssd1/sajjadm/llvm-project/llvm/include /local/ssd1/sajjadm/llvm-project/clang/include/clang/Basic/Diagnostic.td -o tools/clang/include/clang/Basic/DiagnosticParseKinds.inc -d tools/clang/include/clang/Basic/DiagnosticParseKinds.inc.d
> pure virtual method called
> terminate called without an active exception
>
> I made a small tweak to the source code (commented out the new function's declaration in InstrProfiling.h) and with that stage 2 compiled cleanly but then stage 3 had a similar problem:
>
> FAILED: lib/Demangle/CMakeFiles/LLVMDemangle.dir/Demangle.cpp.o
> /local/ssd1/sajjadm/llvm-project/stage2/bin/clang++  -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Demangle -I/local/ssd1/sajjadm/llvm-project/llvm/lib/Demangle -I/usr/include/libxml2 -Iinclude -I/local/ssd1/sajjadm/llvm-project/llvm/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG    -fno-exceptions -fno-rtti -MD -MT lib/Demangle/CMakeFiles/LLVMDemangle.dir/Demangle.cpp.o -MF lib/Demangle/CMakeFiles/LLVMDemangle.dir/Demangle.cpp.o.d -o lib/Demangle/CMakeFiles/LLVMDemangle.dir/Demangle.cpp.o -c /local/ssd1/sajjadm/llvm-project/llvm/lib/Demangle/Demangle.cpp
> pure virtual method called
> terminate called without an active exception
>
> My stage 1 compiler is GCC 7.3.0
>
>
>
> On Wed, Jun 12, 2019 at 1:42 AM Hans Wennborg <hans at chromium.org> wrote:
>>
>> We noticed in Chromium (we're trying to start building Clang itself
>> with PGO) that this change is causing IR-instrumented Clang to become
>> crashy. (+gbiv in case he saw similar issues)
>>
>> I've reverted it (and the follow-up with test cases) in r363134.
>>
>> To reproduce on a Linux workstation, in the llvm monorepo checked out
>> at c1867557d93d622f761b57af6e66e3e518bc0b9f / r362676
>>
>> $ ( mkdir build.stage1 && cd build.stage1 && cmake -GNinja
>> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;compiler-rt"
>> ../llvm && ninja )
>> $ ( mkdir build.stage2 && cd build.stage2 &&
>> CC=${PWD}/../build.stage1/bin/clang
>> CXX=${PWD}/../build.stage1/bin/clang++ cmake -GNinja
>> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang
>> -DLLVM_BUILD_INSTRUMENTED=IR ../llvm && ninja clang )
>> $ ( mkdir build.stage3 && cd build.stage3 &&
>> CC=${PWD}/../build.stage2/bin/clang
>> CXX=${PWD}/../build.stage2/bin/clang++ cmake -GNinja
>> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang ../llvm &&
>> ninja clang )
>>
>> The instrumented Clang now crashes pretty soon, in this case:
>>
>> [5/2833] Building CXX object
>> lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.cpp.o
>> FAILED: lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.cpp.o
>> /work/llvm.monorepo/build.stage2/bin/clang++  -DGTEST_HAS_RTTI=0
>> -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
>> -D__STDC_LIMIT_MACROS -Ilib/Support
>> -I/work/llvm.monorepo/llvm/lib/Support -I/usr/include/libxml2
>> -Iinclude -I/work/llvm.monorepo/llvm/include -fPIC
>> -fvisibility-inlines-hidden -Werror=date-time
>> -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra
>> -Wno-unused-parameter -Wwrite-strings -Wcast-qual
>> -Wmissing-field-initializers -pedantic -Wno-long-long
>> -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type
>> -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion
>> -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG
>>  -fno-exceptions -fno-rtti -MD -MT
>> lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.cpp.o -MF
>> lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.cpp.o.d -o
>> lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.cpp.o -c
>> /work/llvm.monorepo/llvm/lib/Support/ConvertUTF.cpp
>> /work/llvm.monorepo/build.stage2/bin/clang++(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x27)[0x2b98537]
>> /work/llvm.monorepo/build.stage2/bin/clang++[0x2b98c3f]
>> /lib/x86_64-linux-gnu/libpthread.so.0(+0x123a0)[0x7f8ad19a03a0]
>> /work/llvm.monorepo/build.stage2/bin/clang++[0x5817d2b]
>> /work/llvm.monorepo/build.stage2/bin/clang++[0x5817c42]
>> /work/llvm.monorepo/build.stage2/bin/clang++[0x58172e2]
>> /lib/x86_64-linux-gnu/libc.so.6(+0x392ec)[0x7f8ad04942ec]
>> /lib/x86_64-linux-gnu/libc.so.6(+0x3941a)[0x7f8ad049441a]
>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf2)[0x7f8ad047e532]
>> /work/llvm.monorepo/build.stage2/bin/clang++(_start+0x2a)[0xa2b75a]
>>
>> It's interesting to see libpthread.so on the stack. Maybe that
>> suggests recursive locking or something?
>>
>> Trying to recompile just that file with the instrumented Clang works
>> fine, the crash doesn't happen every time (which is why I haven't
>> caught it in a debugger), but running many compilations in parallel
>> reproduces the issue fairly reliably:
>>
>> $ cd build.stage3
>> $ for x in `seq 1 100` ; do ( ../build.stage2/bin/clang++
>> -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support
>> -I../llvm/lib/Support -Iinclude -I../llvm/include -fPIC
>> -fvisibility-inlines-hidden -Werror=date-time
>> -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra
>> -Wno-unused-parameter -Wwrite-strings -Wcast-qual
>> -Wmissing-field-initializers -pedantic -Wno-long-long
>> -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type
>> -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion
>> -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG
>> -fno-exceptions -fno-rtti -c ../llvm/lib/Support/ConvertUTF.cpp -o
>> /dev/null && echo OK ) & done
>>
>> /work/llvm.monorepo/build.stage2/bin/clang-9(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x27)[0x2b98537]
>> /work/llvm.monorepo/build.stage2/bin/clang-9[0x2b98c3f]
>> /lib/x86_64-linux-gnu/libpthread.so.0(+0x123a0)[0x7fd08f2bf3a0]
>> /work/llvm.monorepo/build.stage2/bin/clang-9[0x5817d2b]
>> /work/llvm.monorepo/build.stage2/bin/clang-9[0x5817c42]
>> /work/llvm.monorepo/build.stage2/bin/clang-9[0x58172e2]
>> /lib/x86_64-linux-gnu/libc.so.6(+0x392ec)[0x7fd08ddb32ec]
>> /lib/x86_64-linux-gnu/libc.so.6(+0x3941a)[0x7fd08ddb341a]
>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf2)[0x7fd08dd9d532]
>> /work/llvm.monorepo/build.stage2/bin/clang-9(_start+0x2a)[0xa2b75a]
>> clang-9: error: unable to execute command: Segmentation fault
>> clang-9: error: clang frontend command failed due to signal (use -v to
>> see invocation)
>> clang version 9.0.0 (https://github.com/llvm/llvm-project
>> c1867557d93d622f761b57af6e66e3e518bc0b9f)
>> Target: x86_64-unknown-linux-gnu
>> Thread model: posix
>> InstalledDir: /work/llvm.monorepo/build.stage3/../build.stage2/bin
>>
>>
>> On Thu, Jun 6, 2019 at 8:32 AM Xinliang David Li via llvm-commits
>> <llvm-commits at lists.llvm.org> wrote:
>> >
>> > Author: davidxl
>> > Date: Wed Jun  5 23:35:18 2019
>> > New Revision: 362676
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=362676&view=rev
>> > Log:
>> > [Profile]: Add runtime interface to specify file handle for profile data.
>> >
>> > Author: Sajjad Mirza
>> >
>> > Differential Revision: http://reviews.llvm.org/D62541


More information about the llvm-commits mailing list