Q: link order for lldb

Hi,

I got to the point where I can link on cygwin. I am using
configure/make to build, but at the moment it seems to be
a bit broken and on cygwin does not produce proper link command.

I just want to link for now :slight_smile: so I am fiddling with Makefile
and running into link problems like:

.../lib/liblldbExpression.a(DWARFExpression.o):DWARFExpression.cpp:(.text+0x1d74):
undefined reference to`lldb_private::DataEncoder::~DataEncoder()'

I do not think I have a complete nor even correct link order (pasted
below for reference) and the moment I do not have access to OS X
nor Linux machine to check.

Is there a way to determine proper order of dependencies for lldb?

Paweł

-llldbAPI -llldbBreakpoint -llldbCommands \
-llldbCore -llldbExpression -llldbHostCommon -llldbInitAndLog \
-llldbInterpreter -llldbPluginABIMacOSX_arm -llldbPluginABIMacOSX_i386 \
-llldbPluginABISysV_x86_64 -llldbPluginDisassemblerLLVM \
-llldbPluginDynamicLoaderStatic -llldbPluginEmulateInstructionARM \
-llldbPluginLanguageRuntimeCPlusPlusItaniumABI \
-llldbPluginLanguageRuntimeObjCAppleObjCRuntime \
-llldbPluginObjectContainerBSDArchive -llldbPluginObjectFileELF \
-llldbPluginObjectFilePECOFF -llldbPluginPlatformGDBServer \
-llldbPluginProcessGDBRemote -llldbPluginSymbolFileDWARF \
-llldbPluginSymbolFileSymtab -llldbPluginUnwindAssemblyInstEmulation \
-llldbPluginUnwindAssemblyx86 -llldbPluginUtility -llldbSymbol \
-llldbTarget -llldbUtility -lclangAnalysis -lclangAST -lclangBasic \
-lclangCodeGen -lclangFrontend -lclangDriver -lclangEdit \
-lclangLex -lclangRewriteCore -lclangRewriteFrontend -lclangParse
-lclangSema -lclangSerialization \
-lLLVMMCDisassembler -llldbPluginPlatformMacOSX \
-llldbPluginPlatformLinux -llldbPluginPlatformFreeBSD \
-llldbPluginDynamicLoaderPOSIX -Wl,--no-whole-archive \
-lLLVMLinker -lLLVMArchive -lLLVMMCJIT -lLLVMJIT -lLLVMRuntimeDyld \
-lLLVMExecutionEngine -lLLVMipo -lLLVMVectorize -lLLVMInstrumentation \
-lLLVMBitWriter -lLLVMBitReader -lLLVMAsmParser -lLLVMX86AsmParser \
-lLLVMX86Disassembler -lLLVMX86CodeGen -lLLVMSelectionDAG \
-lLLVMAsmPrinter -lLLVMMCParser -lLLVMCodeGen -lLLVMScalarOpts \
-lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis \
-lLLVMX86Desc -lLLVMX86Info -lLLVMTarget -lLLVMX86AsmPrinter -lLLVMMC \
-lLLVMObject -lLLVMX86Utils -lLLVMCore -lLLVMSupport -Wl,--no-undefined \
-lpthread -ldl -lm

I'm not sure how it works on Windows -- cygwin can be finicky sometimes. On Linux though, the following linker invocation works:

llvm[3]: Linking Debug+Asserts Shared Library liblldb.so
g++ -I/home/baldrick/lldb/build/include -I/home/baldrick/lldb/build/tools/lldb/lib -I/home/baldrick/lldb/llvm/include -I/home/baldrick/lldb/llvm/tools/lldb/lib -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -g -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -fPIC -Woverloaded-virtual -Wcast-qual -std=c++0x -g -Wl,-R -Wl,'$ORIGIN' -L/home/baldrick/lldb/build/Debug+Asserts/lib -L/home/baldrick/lldb/build/Debug+Asserts/lib -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-uninitialized -shared -o /home/baldrick/lldb/build/Debug+Asserts/lib/liblldb.so \
    -Wl,--whole-archive -llldbAPI -llldbBreakpoint -llldbCommands -llldbCore -llldbExpression -llldbHostCommon -llldbInitAndLog -llldbInterpreter -llldbPluginABIMacOSX_arm -llldbPluginABIMacOSX_i386 -llldbPluginABISysV_x86_64 -llldbPluginDisassemblerLLVM -llldbPluginDynamicLoaderStatic -llldbPluginDynamicLoaderPOSIX -llldbPluginEmulateInstructionARM -llldbPluginLanguageRuntimeCPlusPlusItaniumABI -llldbPluginLanguageRuntimeObjCAppleObjCRuntime -llldbPluginObjectContainerBSDArchive -llldbPluginObjectFileELF -llldbPluginObjectFilePECOFF -llldbPluginOperatingSystemPython -llldbPluginPlatformGDBServer -llldbPluginProcessGDBRemote -llldbPluginSymbolFileDWARF -llldbPluginSymbolFileSymtab -llldbPluginUnwindAssemblyInstEmulation -llldbPluginUnwindAssemblyx86 -llldbPluginUtility -llldbSymbol -llldbTarget -llldbUtility -lclangAnalysis -lclangAST -lclangBasic -lclangCodeGen -lclangFrontend -lclangDriver -lclangEdit -lclangLex -lclangParse -lclangSema -lclangSerialization -lLLVMMCDisassembler -llldbPluginPlatformMacOSX -llldbPluginPlatformLinux -llldbPluginPlatformFreeBSD -lclangRewriteCore -lclangRewriteFrontend -llldbHostLinux -llldbPluginProcessLinux -llldbPluginProcessPOSIX -llldbPluginDynamicLoaderMacOSX -llldbPluginDynamicLoaderDarwinKernel -llldbPluginOperatingSystemDarwinKernel -Wl,--no-whole-archive -lLLVMLinker -lLLVMArchive -lLLVMMCJIT -lLLVMJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMipo -lLLVMVectorize -lLLVMInstrumentation -lLLVMBitWriter -lLLVMBitReader -lLLVMAsmParser -lLLVMHexagonCodeGen -lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMHexagonAsmPrinter -lLLVMNVPTXCodeGen -lLLVMNVPTXDesc -lLLVMNVPTXInfo -lLLVMNVPTXAsmPrinter -lLLVMMBlazeDisassembler -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeAsmPrinter -lLLVMMBlazeAsmParser -lLLVMMBlazeInfo -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreDisassembler -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMXCoreAsmPrinter -lLLVMMipsDisassembler -lLLVMMipsCodeGen -lLLVMMip
sAsmParser -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMPowerPCAsmPrinter -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMX86Desc -lLLVMX86Info -lLLVMTarget -lLLVMX86AsmPrinter -lLLVMMC -lLLVMObject -lLLVMX86Utils -lLLVMCore -lLLVMSupport -Wl,--no-undefined -L/usr/lib/python2.6/config -lpthread -ldl -lutil -lm -lpython2.6 -lrt -lpthread -lrt -ldl -lm

Out of curiosity, what made you abandon the cmake route? I was hoping to take the cmakefiles from the windows branch and port them to Linux at some point... It's somewhat concerning if they are problematic even on Windows.

Best of luck,
Dan

I'm not sure how it works on Windows -- cygwin can be finicky sometimes. On Linux though, the following linker invocation works:

My current fresh cygwin install seems surprising stable,
all random crashes are gone! The only catch so far is the
configure, specifically lldb Makefile.

llvm[3]: Linking Debug+Asserts Shared Library liblldb.so
g++ -I/home/baldrick/lldb/build/include -I/home/baldrick/lldb/build/tools/lldb/lib -I/home/baldrick/lldb/llvm/include -I/home/baldrick/lldb/llvm/tools/lldb/lib -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -g -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -fPIC -Woverloaded-virtual -Wcast-qual -std=c++0x -g -Wl,-R -Wl,'$ORIGIN' -L/home/baldrick/lldb/build/Debug+Asserts/lib -L/home/baldrick/lldb/build/Debug+Asserts/lib -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-uninitialized -shared -o /home/baldrick/lldb/build/Debug+Asserts/lib/liblldb.so \
    -Wl,--whole-archive -llldbAPI -llldbBreakpoint -llldbCommands -llldbCore -llldbExpression -llldbHostCommon -llldbInitAndLog -llldbInterpreter -llldbPluginABIMacOSX_arm -llldbPluginABIMacOSX_i386 -llldbPluginABISysV_x86_64 -llldbPluginDisassemblerLLVM -llldbPluginDynamicLoaderStatic -llldbPluginDynamicLoaderPOSIX -llldbPluginEmulateInstructionARM -llldbPluginLanguageRuntimeCPlusPlusItaniumABI -llldbPluginLanguageRuntimeObjCAppleObjCRuntime -llldbPluginObjectContainerBSDArchive -llldbPluginObjectFileELF -llldbPluginObjectFilePECOFF -llldbPluginOperatingSystemPython -llldbPluginPlatformGDBServer -llldbPluginProcessGDBRemote -llldbPluginSymbolFileDWARF -llldbPluginSymbolFileSymtab -llldbPluginUnwindAssemblyInstEmulation -llldbPluginUnwindAssemblyx86 -llldbPluginUtility -llldbSymbol -llldbTarget -llldbUtility -lclangAnalysis -lclangAST -lclangBasic -lclangCodeGen -lclangFrontend -lclangDriver -lclangEdit -lclangLex -lclangParse -lclangSema -lclangSerialization -lLLVMMCDisass!

embler -
llldbPluginPlatformMacOSX -llldbPluginPlatformLinux -llldbPluginPlatformFreeBSD -lclangRewriteCore -lclangRewriteFrontend -llldbHostLinux -llldbPluginProcessLinux -llldbPluginProcessPOSIX -llldbPluginDynamicLoaderMacOSX -llldbPluginDynamicLoaderDarwinKernel -llldbPluginOperatingSystemDarwinKernel -Wl,--no-whole-archive -lLLVMLinker -lLLVMArchive -lLLVMMCJIT -lLLVMJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMipo -lLLVMVectorize -lLLVMInstrumentation -lLLVMBitWriter -lLLVMBitReader -lLLVMAsmParser -lLLVMHexagonCodeGen -lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMHexagonAsmPrinter -lLLVMNVPTXCodeGen -lLLVMNVPTXDesc -lLLVMNVPTXInfo -lLLVMNVPTXAsmPrinter -lLLVMMBlazeDisassembler -lLLVMMBlazeCodeGen -lLLVMMBlazeDesc -lLLVMMBlazeAsmPrinter -lLLVMMBlazeAsmParser -lLLVMMBlazeInfo -lLLVMCppBackendCodeGen -lLLVMCppBackendInfo -lLLVMMSP430CodeGen -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMSP430AsmPrinter -lLLVMXCoreDisassembler -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMXC!
oreAsmPri
nter -lLLVMMipsDisassembler -lLLVMMipsCodeGen -lLLVMMipsAsmParser -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMMipsAsmPrinter -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser -lLLVMARMDesc -lLLVMARMInfo -lLLVMARMAsmPrinter -lLLVMPowerPCCodeGen -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMPowerPCAsmPrinter -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMX86Desc -lLLVMX86Info -lLLVMTarget -lLLVMX86AsmPrinter -lLLVMMC -lLLVMObject -lLLVMX86Utils -lLLVMCore -lLLVMSupport -Wl,--no-undefined -L/usr/lib/python2.6/config -lpthread -ldl -lutil -lm -lpython2.6 -lrt -lpthread -lrt -ldl -lm

Thank you!

Out of curiosity, what made you abandon the cmake route? I was hoping to take the cmakefiles from the windows branch and port them to Linux at some point... It's somewhat concerning if they are problematic even on Windows.

Problematic - did I say that? I did not abandon cmake, but the
current lldb seems to require MSVC2012 to do a native windows
build and my dev environment is still pinned to MSVC2008.

Since, I just happen to have a leftover llvm+clang 3.2 cygwin
build, it seemed to be the easiest way to try the windows branch.
Actually, I have a bunch of different 3.2 setups so out of habit
I might try some other permutations too.

There is another issue, I had problems compiling
Interpreter/LLDBWrapPython.cpp. Two python callbacks
did not have extern "C" linkage and I had to add that.
I am not sure if this is lldb.swig and/or swig problem
or some scryptology issue.

My swig reports - SWIG Version 2.0.9
is this recent enough for a build?

Best of luck,
Dan

Cheers,
Paweł

Ah I misunderstood the motivation for Cygwin instead of cmake.

Yes, your swig version should be fine. The c linkage problem was fixed in trunk back in r168901.

You may need other gcc fixes applied in order to build correctly; namely 169767, r169185, 168901, 168835, 168827. Or, you could merge most recent trunk :slight_smile:

Cheers,
Dan

Ah I misunderstood the motivation for Cygwin instead of cmake.

Yes, your swig version should be fine. The c linkage problem was fixed in trunk back in r168901.

Good to know.

You may need other gcc fixes applied in order to build correctly; namely 169767, r169185, 168901, 168835, 168827. Or, you could merge most recent trunk :slight_smile:

I will go through the list (thanks!) one by one, merging trunk
would have a cascading effect I would rather avoid.
Even the windows branch is a bit too new for the 3.2.

Cheers,
Dan

It links! It runs!

But all I get is Fail () => 0

Now the head scratching, how to debug the debugger.
I guess I'll start with some pipe making. Also,
the full log below does not show a bunch of NULs after:

thread created
SBCommunication(0x800109d0)::ReadThreadStart () => 1
NULNUNULNULNULNUNULNULNULNUNULNULNULNUNULNULNULNUNULNULNULNUNULNULNULNUNULNUL...

Is this normal?

Paweł

$ ./lldb.exe
SBDebugger::Initialize ()

0x80021738 Broadcaster::Broadcaster("Driver")

SBBroadcaster::SBBroadcaster (name="Driver") => SBBroadcaster(0x80021738)

SBError(0x0)::Fail () => 0

SBError(0x0)::Fail () => 0

0x80022aa8 Broadcaster::Broadcaster("debugger.input")

0x80022aa8 Communication::Communication (name = debugger.input)

0x80022ba0 Broadcaster::Broadcaster("lldb.targetList")

0x80022c18 Listener::Listener('lldb.Debugger')

0x800231a8 Broadcaster::Broadcaster("lldb.command-interpreter")

SBDebugger::Create () => SBDebugger(0x80022a50): Debugger (instance:
"debugger_1", id: 1)

SBDebugger(0x80022a50)::GetCommandInterpreter () =>
SBCommandInterpreter(0x800231a8)

SBDebugger(0x80022a50)::SetErrorFileHandle (fh=0x61187790,
transfer_ownership=0)

SBDebugger(0x80022a50)::SetOutputFileHandle (fh=0x61187720,
transfer_ownership=0)

SBDebugger(0x80022a50)::SetInputFileHandle (fh=0x611876b0,
transfer_ownership=1)

0x80022aa8 Communication::Disconnect ()

0x800466c8 ConnectionFileDescriptor::ConnectionFileDescriptor (fd = 0,
owns_fd = 0)

0x800466c8 ConnectionFileDescriptor::ConnectionFileDescriptor () - could
not make pipe: No error

0x80022aa8 Communication::Disconnect ()

0x80022aa8 Communication::StartReadThread ()

thread created

0x80022aa8 Communication::ReadThread () thread starting...
0x800109d0 Broadcaster::Broadcaster("driver.editline")

0x800466c8 ConnectionFileDescriptor::Read () ::read (fd = 0, dst =
0xfff9c990, dst_len = 1024)...

x800109d0 Broadcaster::Broadcaster("driver.editline")
0x800466c8 ConnectionFileDescriptor::BytesAvailable (timeout_usec = 5000000)

0x800109d0 Communication::Communication (name = driver.editline)

0x800466c8 ConnectionFileDescriptor::BytesAvailable() ::select (nfds =
1, fd = 0, NULL, NULL, timeout = 0xfff9c8b0)...

SBCommunication::SBCommunication (broadcaster_name="driver.editline") =>
SBCommunication(0x800109d0)

0x80010f28 ConnectionFileDescriptor::ConnectionFileDescriptor (fd = 3,
owns_fd = 0)

0x80010f28 ConnectionFileDescriptor::ConnectionFileDescriptor () - could
not make pipe: Resource temporarily unavailable

0x800109d0 Communication::Disconnect ()

SBCommunication(0x800109d0)::AdoptFileDescriptor (fd=3, ownd_fd=0) =>
success

SBCommunication(0x800109d0)::SetReadThreadBytesReceivedCallback
(callback=0x4026e0, baton=0x28ab80) => 1

0x800109d0 Communication::StartReadThread ()

thread created
SBCommunication(0x800109d0)::ReadThreadStart () => 1

SBBroadcaster::SBBroadcaster (name="IOChannel") => SBBroadcaster(0x80011298)

0x800109d0 Communication::ReadThread () thread starting...

0x80010f28 ConnectionFileDescriptor::Read () ::read (fd = 3, dst =
0xffe9c990, dst_len = 1024)...

0x80010f28 ConnectionFileDescriptor::BytesAvailable (timeout_usec = 5000000)

0x80010f28 ConnectionFileDescriptor::BytesAvailable() ::select (nfds =
4, fd = 3, NULL, NULL, timeout = 0xffe9c8b0)...

SBFileSpec(0x800116a0)::GetFilename () => NULL