Xcode suggested enabling a "no common blocks" warning(whatever that is) and wanted to clean up some duplicatedentries in the project files. llvm-svn: 251586
Separate monolithic GDBRemoteCommunicationServer class into 4 partGDBRemoteCommunicationServer: Basic packet handling, handler registrationLLDBCommonPacketHandler: Common packet handling for lldb-
Separate monolithic GDBRemoteCommunicationServer class into 4 partGDBRemoteCommunicationServer: Basic packet handling, handler registrationLLDBCommonPacketHandler: Common packet handling for lldb-platform and lldb-gdbserverLLDBPlatformPacketHandler: lldb-platform specific packet handlingLLGSPacketHandler: lldb-gdbserver specific packet handlingDifferential Revision: http://reviews.llvm.org/D7538llvm-svn: 228823
show more ...
Xcode recommended these changes to the project file. It recommendeda number of warnings to be enabled. The one making the most noiseacross the code base right now is CLANG_WARN_UNREACHABLE_CODE =
Xcode recommended these changes to the project file. It recommendeda number of warnings to be enabled. The one making the most noiseacross the code base right now is CLANG_WARN_UNREACHABLE_CODE = YES.llvm-svn: 219910
Revert r209142.Need to spend a little more time with suppressing the debugserver 64-to-32 bit warnings.Will re-submit after I get the warnings properly suppressed.llvm-svn: 209151
Update Xcode settings for Xcode 5.1 (5B130a) to remove workspace warning.llvm-svn: 209142
Remove stuff from debugserver Xcode project that didn't belong.llvm-svn: 197188
Expose SBPlatform through the public API.Example code:remote_platform = lldb.SBPlatform("remote-macosx"); remote_platform.SetWorkingDirectory("/private/tmp")debugger.SetSelectedPlatform(remote_
Expose SBPlatform through the public API.Example code:remote_platform = lldb.SBPlatform("remote-macosx"); remote_platform.SetWorkingDirectory("/private/tmp")debugger.SetSelectedPlatform(remote_platform)connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111"); err = remote_platform.ConnectRemote(connect_options)if err.Success(): print >> result, 'Connected to remote platform:' print >> result, 'hostname: %s' % (remote_platform.GetHostname()) src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False) dst = lldb.SBFileSpec() # copy src to platform working directory since "dst" is empty err = remote_platform.Install(src, dst); if err.Success(): print >> result, '%s installed successfully' % (src) else: print >> result, 'error: failed to install "%s": %s' % (src, err)Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories.The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform.The API in SBPlatform is subject to change and will be getting many new functions.llvm-svn: 195273
<rdar://problem/13521159>LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.All logg
<rdar://problem/13521159>LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.llvm-svn: 178191
Update the project and schemes to the Xcode recommended settings.llvm-svn: 160391
The second part in thread hardening the internals of LLDB where we makethe lldb_private::StackFrame objects hold onto a weak pointer to the threadobject. The lldb_private::StackFrame objects the th
The second part in thread hardening the internals of LLDB where we makethe lldb_private::StackFrame objects hold onto a weak pointer to the threadobject. The lldb_private::StackFrame objects the the most volatile objectswe have as when we are doing single stepping, frames can often get lost orthrown away, only to be re-created as another object that still refers to thesame frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part ofa thread anymore, and this is the first step (this fix makes that possiblebut doesn't implement it yet).Also changed lldb_private::ExecutionContextScope to return shared pointers toall objects in the execution context to further thread harden the internals.llvm-svn: 150871
Fixed the Xcode project building of LLVM to be a bit more user friendly:- If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LL
Fixed the Xcode project building of LLVM to be a bit more user friendly:- If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM.- If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch- If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built intoarch specific directories and never get merged into universal binaries as thiswas causing issues where you would have to go and delete the file if you wantedto build an extra architecture slice.llvm-svn: 143678
Adding a Xcode workspace for lldb.llvm-svn: 124416