maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/lldb.xcodeproj/xcshareddata/xcschemes/LLDB.xcscheme

103 lines
3.4 KiB
Plaintext
Raw Normal View History

Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
<?xml version="1.0" encoding="UTF-8"?>
<Scheme
<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
2013-03-28 07:08:40 +08:00
LastUpgradeVersion = "0500"
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same 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 of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
version = "1.8">
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
<BuildAction
parallelizeBuildables = "NO"
buildImplicitDependencies = "YES">
<BuildActionEntries>
<BuildActionEntry
buildForTesting = "YES"
buildForRunning = "YES"
buildForProfiling = "YES"
buildForArchiving = "YES"
buildForAnalyzing = "YES">
<BuildableReference
BuildableIdentifier = "primary"
BlueprintIdentifier = "26680206115FD0ED008E1FE4"
BuildableName = "LLDB.framework"
BlueprintName = "LLDB"
ReferencedContainer = "container:lldb.xcodeproj">
</BuildableReference>
</BuildActionEntry>
</BuildActionEntries>
</BuildAction>
<TestAction
Update the project and schemes to the Xcode recommended settings. llvm-svn: 160391
2012-07-18 03:47:06 +08:00
selectedDebuggerIdentifier = "Xcode.DebuggerFoundation.Debugger.LLDB"
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
selectedLauncherIdentifier = "Xcode.DebuggerFoundation.Launcher.GDB"
shouldUseLaunchSchemeArgsEnv = "YES"
buildConfiguration = "Debug">
<Testables>
</Testables>
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same 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 of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
<MacroExpansion>
<BuildableReference
BuildableIdentifier = "primary"
BlueprintIdentifier = "26F5C26910F3D9A4009D5894"
BuildableName = "lldb"
BlueprintName = "lldb-tool"
ReferencedContainer = "container:lldb.xcodeproj">
</BuildableReference>
</MacroExpansion>
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
<EnvironmentVariables>
<EnvironmentVariable
key = "BLUBBY"
value = "YES"
isEnabled = "YES">
</EnvironmentVariable>
</EnvironmentVariables>
</TestAction>
<LaunchAction
selectedDebuggerIdentifier = "Xcode.DebuggerFoundation.Debugger.LLDB"
selectedLauncherIdentifier = "Xcode.DebuggerFoundation.Launcher.LLDB"
displayScaleIsEnabled = "NO"
displayScale = "1.00"
I accidentally committed some changes to the Xcode workspace that aren't actually desirable. Reverted. llvm-svn: 147097
2011-12-22 05:30:33 +08:00
launchStyle = "0"
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
useCustomWorkingDirectory = "NO"
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same 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 of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
buildConfiguration = "Debug"
ignoresPersistentStateOnLaunch = "NO"
debugDocumentVersioning = "YES"
allowLocationSimulation = "YES">
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
<BuildableProductRunnable>
<BuildableReference
BuildableIdentifier = "primary"
BlueprintIdentifier = "26F5C26910F3D9A4009D5894"
BuildableName = "lldb"
BlueprintName = "lldb-tool"
ReferencedContainer = "container:lldb.xcodeproj">
</BuildableReference>
</BuildableProductRunnable>
<EnvironmentVariables>
<EnvironmentVariable
key = "BLUBBY"
value = "YES"
isEnabled = "YES">
</EnvironmentVariable>
</EnvironmentVariables>
<AdditionalOptions>
</AdditionalOptions>
</LaunchAction>
<ProfileAction
displayScaleIsEnabled = "NO"
displayScale = "1.00"
shouldUseLaunchSchemeArgsEnv = "YES"
savedToolIdentifier = ""
useCustomWorkingDirectory = "NO"
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same 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 of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
buildConfiguration = "Release"
debugDocumentVersioning = "YES">
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
<EnvironmentVariables>
<EnvironmentVariable
key = "BLUBBY"
value = "YES"
isEnabled = "YES">
</EnvironmentVariable>
</EnvironmentVariables>
</ProfileAction>
<AnalyzeAction
buildConfiguration = "Debug">
</AnalyzeAction>
<ArchiveAction
buildConfiguration = "Release"
revealArchiveInOrganizer = "YES">
</ArchiveAction>
</Scheme>