[lldb-dev] Heads up: LLDB is broken with LLVM at ToT
Zachary Turner
zturner at google.com
Tue Dec 9 15:04:04 PST 2014
I filed the bug anyway, can't hurt to try reproducing on other platforms.
On Tue Dec 09 2014 at 2:56:24 PM Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:
> Ah. No :/.
>
>
> > On 2014 Dec 9, at 14:55, Zachary Turner <zturner at google.com> wrote:
> >
> > Do you have access to a Windows machien to test on? I suspect it's
> going to require Windows to reproduce.
> >
> > On Tue Dec 09 2014 at 2:54:44 PM Duncan P. N. Exon Smith <
> dexonsmith at apple.com> wrote:
> > Weird, it passed an LTO bootstrap for me.
> >
> > Is it possible to file a PR with a testcase? I'll look at it right
> > away.
> >
> > > On 2014 Dec 9, at 14:50, Zachary Turner <zturner at google.com> wrote:
> > >
> > > Just an additional heads up that there may be some runtime issues with
> the patch as well.
> > >
> > > Running this command:
> > > d:\src\llvm\build\ninja\bin\clang++.exe -std=c++11 -g -O0 -m32
> -Id:/src/llvm/tools/lldb/test/make/../../include -fno-exceptions
> -include d:/src/llvm/tools/lldb/test/make/uncaught_exception.h
> -D_HAS_EXCEPTIONS=0 -O0 -c -o main.o main.cpp
> > >
> > > Results in this:
> > >
> > > Stack dump:
> > > 0. Program arguments: d:\src\llvm\build\ninja\bin\clang++.exe
> -cc1 -triple i686-pc-windows-msvc -emit-obj -mrelax-all -disable-free
> -main-file-name main.cpp -mrelocation-model static -mthread-model posix
> -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
> -target-cpu pentium4 -g
> > > -dwarf-column-info -coverage-file d:\src\llvm\tools\lldb\test\
> functionalities\data-formatter\data-formatter-stl\libcxx\vbool\main.o
> -resource-dir d:\src\llvm\build\ninja\bin\..\lib\clang\3.6.0 -include
> d:/src/llvm/tools/lldb/test/make/uncaught_exception.h -D
> _HAS_EXCEPTIONS=0 -I d:/src/llvm/tools/ll
> > > db/test/make/../../include -internal-isystem
> d:\src\llvm\build\ninja\bin\..\lib\clang\3.6.0\include -internal-isystem
> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include
> -internal-isystem C:\Program Files (x86)\Windows Kits\8.1\include\shared
> -internal-isystem C:\Program Files (x86)\Windo
> > > ws Kits\8.1\include\um -internal-isystem C:\Program Files
> (x86)\Windows Kits\8.1\include\winrt -O0 -std=c++11 -fdeprecated-macro
> -fdebug-compilation-dir d:\src\llvm\tools\lldb\test\functionalities\data-
> formatter\data-formatter-stl\libcxx\vbool -ferror-limit 19
> -fmessage-length 300 -mstackrealign -fm
> > > s-extensions -fms-compatibility -fms-compatibility-version=17.00
> -fdelayed-template-parsing -fobjc-runtime=gcc -fdiagnostics-show-option
> -fcolor-diagnostics -o main.o -x c++ main.cpp
> > > 1. <eof> parser at end of file
> > > 2. Per-file LLVM IR generation
> > > 0x578AAA3B (0x07C903C4 0x07C903E4 0x07C903E4 0x05D8E590), ??3 at YAXPAX@Z()
> + 0xAB bytes(s)
> > > 0x01242744 (0x07C903E4 0x07C903E4 0x05D8E5AC 0x01242B8A),
> llvm::MDNode::operator delete() + 0x34 bytes(s),
> d:\src\llvm\lib\ir\metadata.cpp, line 388 + 0x14 byte(s)
> > > 0x0124D367 (0x00000001 0x00000000 0xCCCCCCCC 0x07C903E4),
> llvm::MDNodeFwdDecl::`scalar deleting destructor'() + 0x27 bytes(s)
> > > 0x01242B8A (0x07C903E4 0x05D8E788 0x05D8E7FC 0xCCCCCCCC),
> llvm::MDNode::deleteTemporary() + 0x8A bytes(s),
> d:\src\llvm\lib\ir\metadata.cpp, line 591 + 0x25 byte(s)
> > > 0x01148933 (0x06150E78 0x07C903E4 0x05D8E7E4 0x05D8E7FC),
> llvm::DIDescriptor::replaceAllUsesWith() + 0x123 bytes(s),
> d:\src\llvm\lib\ir\debuginfo.cpp, line 342 + 0x9 byte(s)
> > > 0x01C824B7 (0x05D8E848 0x05D8E7FC 0xCCCCCCCC 0xCCCCCCCC),
> clang::CodeGen::CGDebugInfo::finalize() + 0x2A7 bytes(s),
> d:\src\llvm\tools\clang\lib\codegen\cgdebuginfo.cpp, line 3390
> > > 0x01C112BB (0x0618BE90 0x05D8E848 0x01BEFB40 0x0617DDE0),
> clang::CodeGen::CodeGenModule::Release() + 0x3CB bytes(s),
> d:\src\llvm\tools\clang\lib\codegen\codegenmodule.cpp, line 415
> > > 0x01C0E576 (0x0617DDE0 0x05D8E8D0 0x05D8E854 0xCCCCCCCC), `anonymous
> namespace'::CodeGeneratorImpl::HandleTranslationUnit() + 0x86 bytes(s),
> d:\src\llvm\tools\clang\lib\codegen\modulebuilder.cpp, line 198
> > > 0x01BEFB40 (0x0617DDE0 0x05D8EAD0 0x05D8E8E0 0x061B8890),
> clang::BackendConsumer::HandleTranslationUnit() + 0x60 bytes(s),
> d:\src\llvm\tools\clang\lib\codegen\codegenaction.cpp, line 131 + 0x21
> byte(s)
> > > 0x025B1717 (0x061A2460 0x00000000 0x00000000 0x05D8EAD8),
> clang::ParseAST() + 0x237 bytes(s), d:\src\llvm\tools\clang\lib\parse\parseast.cpp,
> line 154 + 0x18 byte(s)
> > > 0x018BF641 (0x05D8EB54 0x05D8EAD8 0xCCCCCCCC 0xCCCCCCCC),
> clang::ASTFrontendAction::ExecuteAction() + 0x101 bytes(s),
> d:\src\llvm\tools\clang\lib\frontend\frontendaction.cpp, line 527 + 0x30
> byte(s)
> > > 0x01BEC33F (0x05D8EB00 0xCCCCCCCC 0xCCCCCCCC 0xCCCCCCCC),
> clang::CodeGenAction::ExecuteAction() + 0x3CF bytes(s),
> d:\src\llvm\tools\clang\lib\codegen\codegenaction.cpp, line 729
> > > 0x018BF22E (0x05D8EBF8 0x00000000 0xCCCCCCCC 0xCCCCCCCC),
> clang::FrontendAction::Execute() + 0x7E bytes(s),
> d:\src\llvm\tools\clang\lib\frontend\frontendaction.cpp, line 428 + 0xF
> byte(s)
> > > 0x0187A821 (0x06158390 0x05D8F100 0x00000000 0xCCCCCCCC),
> clang::CompilerInstance::ExecuteAction() + 0x2A1 bytes(s),
> d:\src\llvm\tools\clang\lib\frontend\compilerinstance.cpp, line 812
> > > 0x019CDDBE (0x06152A98 0x05D8FEC8 0xCCCCCCCC 0xCCCCCCCC), clang::ExecuteCompilerInvocation()
> + 0x30E bytes(s), d:\src\llvm\tools\clang\lib\frontendtool\executecompilerinvocation.cpp,
> line 222 + 0x11 byte(s)
> > > 0x0041461F (0x05D8FAB0 0x0000003D 0x06155AD0 0x0035139D), cc1_main() +
> 0x2FF bytes(s), d:\src\llvm\tools\clang\tools\driver\cc1_main.cpp, line
> 110 + 0xE byte(s)
> > > 0x003FFC18 (0x05D8FAA8 0x0000003F 0x06155AFC 0x00000000),
> ExecuteCC1Tool() + 0x78 bytes(s), d:\src\llvm\tools\clang\tools\driver\driver.cpp,
> line 369 + 0x2B byte(s)
> > > 0x003FFFB5 (0x0000003F 0x061519E8 0x06145120 0x5DB515C0), main() +
> 0x2F5 bytes(s), d:\src\llvm\tools\clang\tools\driver\driver.cpp, line 415
> + 0x33 byte(s)
> > > 0x034BDA89 (0x05D8FF2C 0x75CC919F 0x7EDD4000 0x05D8FF70),
> __tmainCRTStartup() + 0x199 bytes(s), f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c,
> line 626 + 0x19 byte(s)
> > > 0x034BDBCD (0x7EDD4000 0x05D8FF70 0x77A40BBB 0x7EDD4000),
> mainCRTStartup() + 0xD bytes(s), f:\dd\vctools\crt\crtw32\dllstuff\crtexe.c,
> line 466
> > > 0x75CC919F (0x7EDD4000 0x2F016EAA 0x00000000 0x00000000),
> BaseThreadInitThunk() + 0xE bytes(s)
> > > 0x77A40BBB (0xFFFFFFFF 0x77A2C9D1 0x00000000 0x00000000),
> RtlInitializeExceptionChain() + 0x84 bytes(s)
> > > 0x77A40B91 (0x034BDBC0 0x7EDD4000 0x00000000 0x00000000),
> RtlInitializeExceptionChain() + 0x5A bytes(s)
> > > ^C
> > > d:\src\llvm\tools\lldb\test\functionalities\data-
> formatter\data-formatter-stl\libcxx\vbool>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Tue Dec 09 2014 at 2:41:09 PM Duncan P. N. Exon Smith <
> dexonsmith at apple.com> wrote:
> > > Awesome, thanks for the help!
> > >
> > > > On 2014 Dec 9, at 14:28, Zachary Turner <zturner at google.com> wrote:
> > > >
> > > > This fixes the issue. I will check in your patch. Thanks!
> > > >
> > > > On Tue Dec 09 2014 at 2:20:02 PM Zachary Turner <zturner at google.com>
> wrote:
> > > > Testing now. I notice a few of the changes aren't actually
> required in order to fix compiler errors. For example, this line:
> > > >
> > > > - ConstantInt *constant_int = dyn_cast<ConstantInt>(alloc_
> md->getOperand(0));
> > > > + ConstantInt *constant_int = mdconst::dyn_extract<
> ConstantInt>(alloc_md->getOperand(0));
> > > >
> > > > wasn't actually failing. Not sure if that's important, but I'm
> using your fixed version anyway.
> > > >
> > > > On Tue Dec 09 2014 at 2:11:08 PM Duncan P. N. Exon Smith <
> dexonsmith at apple.com> wrote:
> > > > Attaching a patch that should fix it. Can you try compiling?
> > > >
> > > >
> > > >
> > > >
> > > > > On 2014 Dec 9, at 14:03, Zachary Turner <zturner at google.com>
> wrote:
> > > > >
> > > > > Here's the 3 errors.
> > > > >
> > > > > ..\..\tools\lldb\source\Expression\IRForTarget.cpp(413) : error
> C2678: binary '!=' : no operator found which takes a left-hand operand of
> type 'const llvm::MDOperand' (or there is no acceptable conversion)
> > > > > d:\src\llvm\include\llvm/ADT/APSInt.h(291): could be
> 'bool llvm::operator !=(int64_t,const llvm::APSInt &)'
> > > > > d:\src\llvm\include\llvm/ADT/APInt.h(1724): or
> 'bool llvm::operator !=(uint64_t,const llvm::APInt &)'
> > > > > d:\src\llvm\include\llvm/ADT/StringRef.h(527): or
> 'bool llvm::operator !=(llvm::StringRef,llvm::StringRef)'
> > > > > while trying to match the argument list '(const
> llvm::MDOperand, const llvm::GlobalValue *)'
> > > > >
> > > > >
> > > > >
> > > > > ..\..\tools\lldb\source\Expression\IRForTarget.cpp(647) : error
> C2664: 'llvm::MDNode *llvm::MDNode::get(llvm::LLVMContext
> &,llvm::ArrayRef<llvm::Metadata *>)' : cannot convert argument 2 from
> 'llvm::ArrayRef<llvm::Value *>' to 'llvm::ArrayRef<llvm::Metadata *>'
> > > > > No user-defined-conversion operator available that can
> perform this conversion, or the operator cannot be called
> > > > >
> > > > >
> > > > > ..\..\tools\lldb\source\Expression\IRForTarget.cpp(1254) : error
> C2664: 'llvm::MDNode *llvm::MDNode::get(llvm::LLVMContext
> &,llvm::ArrayRef<llvm::Metadata *>)' : cannot convert argument 2 from
> 'llvm::ArrayRef<llvm::Value *>' to 'llvm::ArrayRef<llvm::Metadata *>'
> > > > > No user-defined-conversion operator available that can
> perform this conversion, or the operator cannot be called
> > > > >
> > > > >
> > > > > On Tue Dec 09 2014 at 1:56:03 PM Zachary Turner <
> zturner at google.com> wrote:
> > > > > I'm not sure what the status of building LLDB with CMake is, but
> the normal way apple people build LLDB is to structure the directory like
> this:
> > > > >
> > > > > lldb
> > > > > --llvm
> > > > > ----tools
> > > > > ------clang
> > > > >
> > > > > Then open the xcode workspace and build the lldb-tool target.
> > > > >
> > > > > I'll sync to ToT again though so that I can get you a dump of the
> compiler errors I'm seeing.
> > > > >
> > > > > On Tue Dec 09 2014 at 1:52:40 PM Duncan P. N. Exon Smith <
> dexonsmith at apple.com> wrote:
> > > > > I'm trying to build lldb now, but it's hung trying to build LLVM
> and
> > > > > clang... but I already built these? I don't really understand.
> > > > >
> > > > > Is there any way to make lldb point to my LLVM checkout? I just
> want to
> > > > > see the compiler errors so I can fix them :(.
> > > > >
> > > > > Alternatively, if some can email me a compile log with all the
> errors
> > > > > (can you do a `make -k` or something?) I can send you a patch...
> this is
> > > > > mechanical to update, but I need the compiler to tell me what's
> wrong.
> > > > >
> > > > > I expect the fixes to all be along these lines:
> > > > >
> > > > > - Value *Ops[] => Metadata *Ops[]
> > > > >
> > > > > - cast<ConstantInt>(N->getOperand(0)) =>
> > > > > mdconst::extract<ConstantInt>(N->getOperand(0))
> > > > >
> > > > > - Value *Op = ConstantInt::get(...) =>
> > > > > Metadata *Op = ConstantAsMetadata::get(ConstantInt::get(...))
> > > > >
> > > > > Sorry for the breakage :(.
> > > > >
> > > > > > On 2014 Dec 9, at 13:41, Zachary Turner <zturner at google.com>
> wrote:
> > > > > >
> > > > > > If you sync llvm past git revision db7b69e3a634c5fdff0eceeee2a41ee49c3270a2
> (svn r223802), your LLDB build will be broken.
> > > > > >
> > > > > > I was able to fix one of the errors, but this isn't really my
> area of expertise, so I stopped when I realized I didn't know what I was
> doing.
> > > > > >
> > > > > > Just a warning not to sync LLVM until this is fixed. I've CC'ed
> Sean and Duncan as they are probably the best people to fix this, but if
> anyone else knows how to fix it, feel free.
> > > > >
> > > >
> > >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141209/157dffc4/attachment.html>
More information about the lldb-dev
mailing list