Page MenuHomePhabricator

Resubmit of rL345008 "Split MachinePipeliner code into header and cpp files"
ClosedPublic

Authored by lsaba on Dec 26 2018, 5:39 AM.

Details

Summary

I would like to try to resubmit this patch which was approved in https://reviews.llvm.org/D53477
The patch was reverted since it broke the build in http://green.lab.llvm.org/green//job/lldb-cmake/
Unfortunately the logs were already expired by the time I saw the comment. I tried to locally reproduce but was unable to see an error.
I will revert the commit if the error appears, this will allow me to view the error log for that run.
Alternatively, If someone can help with re-running this patch on http://green.lab.llvm.org/green//job/lldb-cmake/ that would be appreciated!

Diff Detail

Repository
rL LLVM

Event Timeline

lsaba created this revision.Dec 26 2018, 5:39 AM

I have no objections against the such approach, but I'm not sure if this acceptable by the LLVM development rules... Let's ask about it a more experienced participant?

lsaba added a comment.Jan 2 2019, 7:22 AM

Ping2
@craig.topper is this okay with you?

This revision is now accepted and ready to land.Jan 2 2019, 10:19 AM
This revision was automatically updated to reflect the committed changes.

Hello lsaba, sorry for having to revert this after it broke http://green.lab.llvm.org/green/job/lldb-cmake/ again.
I tried to find the root cause, but so far didn't succeed. I will continue tomorrow and keep you in the loop so you can land this as soon as possible.

@aprantl Found a workaround for the lldb-cmake bot: https://reviews.llvm.org/rL350346

I tested it locally with your patch reapplied and the error is fixed. Sorry again for the hassle. Please submit your patch. Thanks

lsaba added a comment.Jan 4 2019, 2:36 AM

@aprantl Found a workaround for the lldb-cmake bot: https://reviews.llvm.org/rL350346

I tested it locally with your patch reapplied and the error is fixed. Sorry again for the hassle. Please submit your patch. Thanks

Thanks for the help! I will try to resubmit

lsaba added a comment.Jan 6 2019, 8:49 AM

@aprantl Found a workaround for the lldb-cmake bot: https://reviews.llvm.org/rL350346

I tested it locally with your patch reapplied and the error is fixed. Sorry again for the hassle. Please submit your patch. Thanks

@aprantl , @sgraenitz , I tried to resbumit the patch in https://reviews.llvm.org/rL350493 but unfortunately issues with the modules still appear: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/314/steps/test/logs/stdio

it is now able to build but the lit test SymbolFile/PDB/class-layout.test is failing:

$ ":" "RUN: at line 4"
$ "E:\build_slave\lldb-x64-windows-ninja\build\bin\lldb-test.EXE" "symbols" "E:\build_slave\lldb-x64-windows-ninja\build\tools\lldb\lit\SymbolFile\PDB\Output/ClassLayoutTest.cpp.exe"

command stderr:

error: Module has no symbol vendor.

error: command failed with exit status: 1
$ "E:\build_slave\lldb-x64-windows-ninja\build\bin\FileCheck.EXE" "E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\PDB\class-layout.test"

command stderr:

E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\PDB\class-layout.test:15:8: error: CHECK: expected string not found in input
CHECK: Module [[MOD:.*]]

^

<stdin>:1:1: note: scanning from here
Module: E:\build_slave\lldb-x64-windows-ninja\build\tools\lldb\lit\SymbolFile\PDB\Output/ClassLayoutTest.cpp.exe

I have reverted the patch again for now as I am unable to reproduce the issue locally, your help will be much apprecicated

@aprantl Found a workaround for the lldb-cmake bot: https://reviews.llvm.org/rL350346

I tested it locally with your patch reapplied and the error is fixed. Sorry again for the hassle. Please submit your patch. Thanks

@aprantl , @sgraenitz , I tried to resbumit the patch in https://reviews.llvm.org/rL350493 but unfortunately issues with the modules still appear: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/314/steps/test/logs/stdio

it is now able to build but the lit test SymbolFile/PDB/class-layout.test is failing:

$ ":" "RUN: at line 4"
$ "E:\build_slave\lldb-x64-windows-ninja\build\bin\lldb-test.EXE" "symbols" "E:\build_slave\lldb-x64-windows-ninja\build\tools\lldb\lit\SymbolFile\PDB\Output/ClassLayoutTest.cpp.exe"

  1. command stderr: error: Module has no symbol vendor.

error: command failed with exit status: 1
$ "E:\build_slave\lldb-x64-windows-ninja\build\bin\FileCheck.EXE" "E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\PDB\class-layout.test"

  1. command stderr: E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\PDB\class-layout.test:15:8: error: CHECK: expected string not found in input CHECK: Module [[MOD:.*]] ^ <stdin>:1:1: note: scanning from here Module: E:\build_slave\lldb-x64-windows-ninja\build\tools\lldb\lit\SymbolFile\PDB\Output/ClassLayoutTest.cpp.exe

I have reverted the patch again for now as I am unable to reproduce the issue locally, your help will be much apprecicated

Even though this error also has Module in the name, this is a completely unrelated issue. Unfortunately Module is a terribly overloaded term. Are you sure that this was actually caused by your commit? It sounds unlikely.

lsaba added a comment.Jan 7 2019, 11:18 AM

@aprantl Found a workaround for the lldb-cmake bot: https://reviews.llvm.org/rL350346

I tested it locally with your patch reapplied and the error is fixed. Sorry again for the hassle. Please submit your patch. Thanks

@aprantl , @sgraenitz , I tried to resbumit the patch in https://reviews.llvm.org/rL350493 but unfortunately issues with the modules still appear: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/314/steps/test/logs/stdio

it is now able to build but the lit test SymbolFile/PDB/class-layout.test is failing:

$ ":" "RUN: at line 4"
$ "E:\build_slave\lldb-x64-windows-ninja\build\bin\lldb-test.EXE" "symbols" "E:\build_slave\lldb-x64-windows-ninja\build\tools\lldb\lit\SymbolFile\PDB\Output/ClassLayoutTest.cpp.exe"

  1. command stderr: error: Module has no symbol vendor.

error: command failed with exit status: 1
$ "E:\build_slave\lldb-x64-windows-ninja\build\bin\FileCheck.EXE" "E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\PDB\class-layout.test"

  1. command stderr: E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\lit\SymbolFile\PDB\class-layout.test:15:8: error: CHECK: expected string not found in input CHECK: Module [[MOD:.*]] ^ <stdin>:1:1: note: scanning from here Module: E:\build_slave\lldb-x64-windows-ninja\build\tools\lldb\lit\SymbolFile\PDB\Output/ClassLayoutTest.cpp.exe

I have reverted the patch again for now as I am unable to reproduce the issue locally, your help will be much apprecicated

Even though this error also has Module in the name, this is a completely unrelated issue. Unfortunately Module is a terribly overloaded term. Are you sure that this was actually caused by your commit? It sounds unlikely.

My commit was the only one in this build which made me suspect it...
I had other failures reported later on, are those also unrelated to said modules ?
in second stage compile in http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/21662/steps/compile.llvm.stage2/logs/stdio

0. /home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.src/tools/clang/include/clang/Frontend/Utils.h:24:2: current parser token 'include'
#0 0x0000000003fd06e9 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x3fd06e9)
#1 0x0000000003fd0919 PrintStackTraceSignalHandler(void*) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x3fd0919)
#2 0x0000000003fcce42 llvm::sys::RunSignalHandlers() (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x3fcce42)
#3 0x0000000003fd32c8 SignalHandler(int) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x3fd32c8)
#4 0x00007fe359bf5890 restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
#5 0x0000000003f00355 llvm::MemoryBuffer::init(char const*, char const*, bool) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x3f00355)
#6 0x0000000003f05107 (anonymous namespace)::MemoryBufferMMapFile<llvm::MemoryBuffer>::MemoryBufferMMapFile(bool, int, unsigned long, unsigned long, std::
1::error_code&) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x3f05107)
#7 0x0000000003f0233d llvm::ErrorOr<std::1::unique_ptr<llvm::MemoryBuffer, std::1::default_delete<llvm::MemoryBuffer> > > getOpenFileImpl<llvm::MemoryBuffer>(int, llvm::Twine const&, unsigned long, unsigned long, long, bool, bool) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x3f0233d)
#8 0x0000000003f02063 llvm::MemoryBuffer::getOpenFile(int, llvm::Twine const&, unsigned long, bool, bool) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x3f02063)
#9 0x00000000091b7551 (anonymous namespace)::RealFile::getBuffer(llvm::Twine const&, long, bool, bool) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x91b7551)
#10 0x00000000042b88bb clang::FileManager::getBufferForFile(clang::FileEntry const*, bool, bool) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x42b88bb)
#11 0x0000000005313291 clang::serialization::ModuleManager::addModule(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, clang::serialization::ModuleFile*, unsigned int, long, long, clang::ASTFileSignature, clang::ASTFileSignature (*)(llvm::StringRef), clang::serialization::ModuleFile*&, std::1::basic_string<char, std::1::char_traits<char>, std::1::allocator<char> >&) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x5313291)
#12 0x00000000050ac8b6 clang::ASTReader::ReadASTCore(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, clang::serialization::ModuleFile*, llvm::SmallVectorImpl<clang::ASTReader::ImportedModule>&, long, long, clang::ASTFileSignature, unsigned int) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x50ac8b6)
#13 0x00000000050c5cba clang::ASTReader::ReadAST(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, unsigned int, llvm::SmallVectorImpl<clang::ASTReader::ImportedSubmodule>*) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x50c5cba)
#14 0x0000000004daeb2e compileAndLoadModule(clang::CompilerInstance&, clang::SourceLocation, clang::SourceLocation, clang::Module*, llvm::StringRef) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x4daeb2e)
#15 0x0000000004daa533 clang::CompilerInstance::loadModule(clang::SourceLocation, llvm::ArrayRef<std::
1::pair<clang::IdentifierInfo*, clang::SourceLocation> >, clang::Module::NameVisibilityKind, bool) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x4daa533)
#16 0x0000000008d9f6f4 clang::Preprocessor::HandleIncludeDirective(clang::SourceLocation, clang::Token&, clang::DirectoryLookup const*, clang::FileEntry const*, bool) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x8d9f6f4)
#17 0x0000000008da1d25 clang::Preprocessor::HandleDirective(clang::Token&) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x8da1d25)
#18 0x0000000008d236bc clang::Lexer::LexTokenInternal(clang::Token&, bool) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x8d236bc)
#19 0x0000000008d1f0c8 clang::Lexer::Lex(clang::Token&) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x8d1f0c8)
#20 0x0000000008e3205b clang::Preprocessor::Lex(clang::Token&) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x8e3205b)
#21 0x00000000074bdf76 clang::Parser::ConsumeAnnotationToken() (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x74bdf76)
#22 0x00000000074bd86a clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x74bd86a)
#23 0x00000000074b41c0 clang::ParseAST(clang::Sema&, bool, bool) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x74b41c0)
#24 0x0000000004e786e9 clang::ASTFrontendAction::ExecuteAction() (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x4e786e9)
#25 0x0000000004e77460 clang::FrontendAction::Execute() (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x4e77460)
#26 0x0000000004da16ae clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x4da16ae)
#27 0x0000000004dd1923 compileModuleImpl(clang::CompilerInstance&, clang::SourceLocation, llvm::StringRef, clang::FrontendInputFile, llvm::StringRef, llvm::StringRef, llvm::function_ref<void (clang::CompilerInstance&)>, llvm::function_ref<void (clang::CompilerInstance&)>)::$_3::operator()() const (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x4dd1923)
#28 0x0000000004dd18e5 void llvm::function_ref<void ()>::callback_fn<compileModuleImpl(clang::CompilerInstance&, clang::SourceLocation, llvm::StringRef, clang::FrontendInputFile, llvm::StringRef, llvm::StringRef, llvm::function_ref<void (clang::CompilerInstance&)>, llvm::function_ref<void (clang::CompilerInstance&)>)::$_3>(long) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x4dd18e5)
#29 0x00000000074ff299 llvm::function_ref<void ()>::operator()() const (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x74ff299)
#30 0x000000000913419b llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x913419b)
#31 0x000000000913446f RunSafelyOnThread_Dispatch(void*) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x913446f)
#32 0x0000000003fd8b50 ExecuteOnThread_Dispatch(void*) (/home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin/clang-7+0x3fd8b50)
#33 0x00007fe359bea6db start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76db)
#34 0x00007fe35883488f clone (/lib/x86_64-linux-gnu/libc.so.6+0x12188f)
clang-7: error: unable to execute command: Bus error (core dumped)
clang-7: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 8.0.0 (trunk 350498)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /home/buildbot/modules-slave-1/clang-x86_64-linux-selfhost-modules/llvm.obj/bin
clang-7: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.

and a test failure in http://green.lab.llvm.org/green/job/lldb-cmake/16358/consoleFull>

FAIL: lldb-Suite :: macosx/queues/TestQueues.py (687 of 1432)

  • TEST 'lldb-Suite :: macosx/queues/TestQueues.py' FAILED ****

lldb version 8.0.99
LLDB library dir: /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin
LLDB import library dir: /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin
libstdcxx tests will not be run because: Don't know how to build with libstdcxx on macosx
Skipping following debug info categories: ['dwo']
Session logs for test failures/errors/unexpected successes will go into directory '/Users/buildslave/jenkins/workspace/lldb-cmake/test/logs'
Command invoked: /Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/test/dotest.py -q --arch=x86_64 -s /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-traces --build-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-build.noindex -S nm -u CXXFLAGS -u CFLAGS --executable /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin/lldb --dsymutil /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin/dsymutil --filecheck /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin/FileCheck -C /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang --codesign-identity lldb_codesign --server /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin/debugserver --arch x86_64 --build-dir /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-build.noindex --session-file-format fm -s=/Users/buildslave/jenkins/workspace/lldb-cmake/test/logs -t --env TERM=vt100 /Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues -p TestQueues.py
Change dir to: /Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues
runCmd: settings set symbols.clang-modules-cache-path "/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-lldb"
output: None
runCmd: settings set symbols.enable-external-lookup false
output: None
os command: make VPATH=/Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues -C /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-build.noindex/macosx/queues/TestQueues.test_with_python_api_dsym -I /Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues -f /Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/Makefile MAKE_DSYM=YES ARCH=x86_64 CC="/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang-8" all
with pid: 58169
stdout: /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang-8 -g -O0 -fno-builtin -arch x86_64 -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/../../make/../../../../../include -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/ -include /Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/../../make/test_common.h -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/../../make/ -fno-limit-debug-info -c -o main.o /Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/main.c
/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang-8 main.o -g -O0 -fno-builtin -arch x86_64 -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/../../make/../../../../../include -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/ -include /Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/../../make/test_common.h -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/../../make/ -fno-limit-debug-info --driver-mode=g++ -o "a.out"
"/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/./bin/dsymutil" -o "a.out.dSYM" "a.out"
stderr:
retcode: 0
<bound method SBProcess.Kill of <lldb.SBProcess; proxy of <Swig Object of type 'lldb::SBProcess *' at 0x10b519d50> >>: success
<bound method SBProcess.Kill of <lldb.SBProcess; proxy of <Swig Object of type 'lldb::SBProcess *' at 0x10b4155d0> >>: success
PASS: LLDB (/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang-8-x86_64) :: test_with_python_api_dsym (TestQueues.TestQueues)
runCmd: settings set symbols.clang-modules-cache-path "/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-lldb"
output: None
runCmd: settings set symbols.enable-external-lookup false
output: None
os command: make VPATH=/Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues -C /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lldb-test-build.noindex/macosx/queues/TestQueues.test_with_python_api_dwarf -I /Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues -f /Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/Makefile MAKE_DSYM=NO ARCH=x86_64 CC="/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang-8"
with pid: 59833
stdout: /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang-8 -g -O0 -fno-builtin -arch x86_64 -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/../../make/../../../../../include -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/ -include /Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/../../make/test_common.h -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/../../make/ -fno-limit-debug-info -c -o main.o /Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/main.c
/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang-8 main.o -g -O0 -fno-builtin -arch x86_64 -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/../../make/../../../../../include -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/ -include /Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/../../make/test_common.h -I/Users/buildslave/jenkins/workspace/lldb-cmake/llvm/tools/lldb/packages/Python/lldbsuite/test/macosx/queues/../../make/ -fno-limit-debug-info --driver-mode=g++ -o "a.out"
stderr:
retcode: 0
<bound method SBProcess.Kill of <lldb.SBProcess; proxy of <Swig Object of type 'lldb::SBProcess *' at 0x10b2d55a0> >>: success
<bound method SBProcess.Kill of <lldb.SBProcess; proxy of <Swig Object of type 'lldb::SBProcess *' at 0x10b415d50> >>: success

Sorry for copying the entire errors from the bots, but I am unable to reproduce locally

Looks like these are unrelated failures. TestQueues started acting up last week because of a concurrency issue. I would recommend you attempt to re-land your commit again and see if any new failures show up. If you are unsure, feel free to ask here or on #llvm on IRC.

lsaba added a comment.Jan 8 2019, 2:07 AM

Looks like these are unrelated failures. TestQueues started acting up last week because of a concurrency issue. I would recommend you attempt to re-land your commit again and see if any new failures show up. If you are unsure, feel free to ask here or on #llvm on IRC.

Thanks, the failures do seem to appear in other unrelated commits. I will try to resubmit

fhahn added a subscriber: fhahn.Jan 8 2019, 12:38 PM

I am seeing lldb-cmake failing again, with the same error as with this patch earlier: http://green.lab.llvm.org/green/job/lldb-cmake/16557/

Did you try your patch with a bootstrap build as suggested in https://reviews.llvm.org/rL350290#304451?

I committed a rather horrible workaround in r350650, but it would be great to revert that again.

What you need to test particularly is building with -DLLVM_ENABLE_MODULES=1.

Hmmm.. my fix didn't go far enough. I reverted this patch once again, so we can sort this out without pressure. As long as you make sure that compiling with -DLLVM_ENABLE_MODULES=1 works, feel free to recommit at any time!

lsaba added a comment.EditedJan 8 2019, 2:34 PM

I committed a rather horrible workaround in r350650, but it would be great to revert that again.

What you need to test particularly is building with -DLLVM_ENABLE_MODULES=1.

@fhahn , @aprantl is this a Mac specific issue? because I tried the suggested bootstrap build with -DLLVM_ENABLE_MODULES=1 on linux and it worked fine. I don't have a Mac machine available to test this..
I am not sure I understand what you mean with making sure it worked with DLLVM_ENABLE_MODULES=1

aprantl added a subscriber: bruno.Jan 8 2019, 5:00 PM

It should not be mac-specific, but it is possible that Linux uses a different default for LLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY. Can you try again with -DLLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY=0 -DLLVM_ENABLE_MODULES=1 ?

llvm/trunk/include/llvm/CodeGen/MachinePipeliner.h
10

This would be nice as a \file Doxygen comment?

lsaba added a comment.EditedJan 9 2019, 6:49 AM

Hmmm.. my fix didn't go far enough. I reverted this patch once again, so we can sort this out without pressure. As long as you make sure that compiling with -DLLVM_ENABLE_MODULES=1 works, feel free to recommit at any

It should not be mac-specific, but it is possible that Linux uses a different default for LLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY. Can you try again with -DLLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY=0 -DLLVM_ENABLE_MODULES=1 ?

I tried to build with the suggested flags but I got unrelated errors on top of trunk without my commits.
The way i'm compiling and building is this:

first build: cmake '-G' 'Ninja' ../../llvm '-DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE' '-DCMAKE_BUILD_TYPE=Release'
(This uses GNU 5.4 compiler to build)

second build: cmake '-G' 'Ninja' ../../llvm '-DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE' '-DCMAKE_BUILD_TYPE=Release' '-DLLVM_VERSION_PATCH=99' '-DLLVM_ENABLE_MODULES=1' -DCMAKE_C_COMPILER=/firstbuild/bin/clang -DCMAKE_CXX_COMPILER=/firstbuild/bin/clang++ -DLLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY=0

without the second flag -DLLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY=0 I don't get errors when building with my patch.. Am i missing something with the compilation flags?

Is there an open bugzilla for this issue? or should I open one?

You have to use clang in order to compile with clang module support enabled. If your host compiler is GCC, you will have to build clang first and then use that clang to compile clang again using all the MODULE cmake options.

lsaba added a comment.Jan 9 2019, 9:08 AM

You have to use clang in order to compile with clang module support enabled. If your host compiler is GCC, you will have to build clang first and then use that clang to compile clang again using all the MODULE cmake options.

this is what i did with my second build stated above, or is that also not enough?

lsaba added a comment.Jan 13 2019, 7:15 AM

You have to use clang in order to compile with clang module support enabled. If your host compiler is GCC, you will have to build clang first and then use that clang to compile clang again using all the MODULE cmake options.

I tried your suggestions and i still have no luck with reproducing this locally..
@aprantl , @sgraenitz @fhahn is anyone actively working on a fix for the issue? who can I assign a Bugzilla to?

I *think* I fixed it for good in in r351077.

I *think* I fixed it for good in in r351077.

That's great news! thank you very much! do you happen to know why the dump function was causing issues in linking?

Roughly: the implementation of print used code (MachineInstr operator<<) that lives in the CodeGen library, and various tools that don't link against CodeGen include header files from the CodeGen Clang module). Without local submodule visibility, this pulls in all headers of the CodeGen Clang module, thus causing code to be generated for the dump function, which then causes the linker error.