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-tool.xcscheme

216 lines
7.5 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
Xcode suggested enabling a "no common blocks" warning (whatever that is) and wanted to clean up some duplicated entries in the project files. llvm-svn: 251586
2015-10-29 08:21:14 +08:00
LastUpgradeVersion = "0720"
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
version = "1.3">
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 = "26F5C26910F3D9A4009D5894"
BuildableName = "lldb"
BlueprintName = "lldb-tool"
ReferencedContainer = "container:lldb.xcodeproj">
</BuildableReference>
</BuildActionEntry>
</BuildActionEntries>
</BuildAction>
<TestAction
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
buildConfiguration = "Debug"
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"
First step in getting LLDB ready to support multiple different type systems. This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system. All tests pass on MacOSX and passed on linux the last time this was submitted. llvm-svn: 244679
2015-08-12 05:38:15 +08:00
selectedLauncherIdentifier = "Xcode.DebuggerFoundation.Launcher.LLDB"
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
shouldUseLaunchSchemeArgsEnv = "YES">
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
<Testables>
</Testables>
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
<MacroExpansion>
<BuildableReference
BuildableIdentifier = "primary"
BlueprintIdentifier = "26F5C26910F3D9A4009D5894"
BuildableName = "lldb"
BlueprintName = "lldb-tool"
ReferencedContainer = "container:lldb.xcodeproj">
</BuildableReference>
</MacroExpansion>
Made the EmulateInstruction class into a plug-in interface and moved the source files around into the places they need to go. llvm-svn: 124631
2011-02-01 08:04:43 +08:00
<CommandLineArguments>
<CommandLineArgument
argument = "/Volumes/work/gclayton/Documents/src/attach/a.out"
Made lldb_private::ArchSpec contain much more than just an architecture. It now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
2011-02-16 05:59:32 +08:00
isEnabled = "NO">
</CommandLineArgument>
<CommandLineArgument
argument = "-a i386 /Volumes/work/gclayton/Documents/src/lldb/test/macosx/universal/testit"
Made the EmulateInstruction class into a plug-in interface and moved the source files around into the places they need to go. llvm-svn: 124631
2011-02-01 08:04:43 +08:00
isEnabled = "YES">
</CommandLineArgument>
</CommandLineArguments>
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
<EnvironmentVariables>
<EnvironmentVariable
key = "LLDB_LAUNCH_FLAG_DISABLE_ASLR"
value = "YES"
isEnabled = "NO">
</EnvironmentVariable>
<EnvironmentVariable
key = "LLDB_LAUNCH_FLAG_LAUNCH_IN_TTY"
value = "YES"
isEnabled = "NO">
</EnvironmentVariable>
<EnvironmentVariable
key = "LLDB_LAUNCH_FLAG_DISABLE_STDIO"
value = "YES"
isEnabled = "NO">
</EnvironmentVariable>
<EnvironmentVariable
key = "LLDB_DEBUGSERVER_PATH"
value = "/tmp/debugserver"
isEnabled = "NO">
</EnvironmentVariable>
<EnvironmentVariable
key = "LLDB_DEBUGSERVER_LOG_FILE"
value = "/tmp/debugserver.txt"
isEnabled = "YES">
</EnvironmentVariable>
<EnvironmentVariable
key = "LLDB_DEBUGSERVER_LOG_FLAGS"
Made the EmulateInstruction class into a plug-in interface and moved the source files around into the places they need to go. llvm-svn: 124631
2011-02-01 08:04:43 +08:00
value = "0x802e0e"
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
isEnabled = "YES">
</EnvironmentVariable>
</EnvironmentVariables>
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
<AdditionalOptions>
</AdditionalOptions>
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
</TestAction>
<LaunchAction
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
buildConfiguration = "DebugClang"
Revert the default debugger to LLDB. llvm-svn: 152263
2012-03-08 07:05:14 +08:00
selectedDebuggerIdentifier = "Xcode.DebuggerFoundation.Debugger.LLDB"
selectedLauncherIdentifier = "Xcode.DebuggerFoundation.Launcher.LLDB"
Add an "offset" option to "break set -n" and "break set -f -l". That way you can set offset breakpoints that will move as the function they are contained in moves (which address breakpoints can't do...) I don't align the new address to instruction boundaries yet, so you have to get this right yourself for now. <rdar://problem/13365575> llvm-svn: 263049
2016-03-10 02:59:13 +08:00
launchStyle = "1"
Remove the custom working directory form the xcscheme. llvm-svn: 131218
2011-05-12 09:34:06 +08:00
useCustomWorkingDirectory = "NO"
Moved all code from ArchDefaultUnwindPlan and ArchVolatileRegs into their respective ABI plugins as they were plug-ins that supplied ABI specfic info. Also hookep up the UnwindAssemblyInstEmulation so that it can generate the unwind plans for ARM. Changed the way ABI plug-ins are handed out when you get an instance from the plug-in manager. They used to return pointers that would be mananged individually by each client that requested them, but now they are handed out as shared pointers since there is no state in the ABI objects, they can be shared. llvm-svn: 131193
2011-05-12 02:39:18 +08:00
customWorkingDirectory = "/Volumes/work/gclayton/Documents/devb/attach"
Remove the "a.out" argument from somewhere on Greg's machine in the lldb-tool run scheme. llvm-svn: 132439
2011-06-02 07:52:04 +08:00
ignoresPersistentStateOnLaunch = "YES"
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
debugDocumentVersioning = "YES"
Add the ability to tag one or more breakpoints with a name. These names can then be used in place of breakpoint id's or breakpoint id ranges in all the commands that operate on breakpoints. <rdar://problem/10103959> llvm-svn: 224392
2014-12-17 07:40:14 +08:00
debugServiceExtension = "internal"
Xcode suggested enabling a "no common blocks" warning (whatever that is) and wanted to clean up some duplicated entries in the project files. llvm-svn: 251586
2015-10-29 08:21:14 +08:00
allowLocationSimulation = "YES"
queueDebuggingEnabled = "No">
Add the ability to tag one or more breakpoints with a name. These names can then be used in place of breakpoint id's or breakpoint id ranges in all the commands that operate on breakpoints. <rdar://problem/10103959> llvm-svn: 224392
2014-12-17 07:40:14 +08:00
<BuildableProductRunnable
runnableDebuggingMode = "0">
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
<BuildableReference
BuildableIdentifier = "primary"
BlueprintIdentifier = "26F5C26910F3D9A4009D5894"
BuildableName = "lldb"
BlueprintName = "lldb-tool"
ReferencedContainer = "container:lldb.xcodeproj">
</BuildableReference>
We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread. To do that we have to spin up a temporary "private state thread" that will respond to events from the lower level process plugins. This check-in should work to do that, but it is still buggy. However, if you don't call functions on the private state thread, these changes make no difference. This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call. llvm-svn: 154230
2012-04-07 08:00:41 +08:00
</BuildableProductRunnable>
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
<EnvironmentVariables>
<EnvironmentVariable
key = "LLDB_LAUNCH_FLAG_DISABLE_ASLR"
value = "YES"
isEnabled = "NO">
</EnvironmentVariable>
<EnvironmentVariable
key = "LLDB_LAUNCH_FLAG_LAUNCH_IN_TTY"
value = "YES"
isEnabled = "NO">
</EnvironmentVariable>
<EnvironmentVariable
key = "LLDB_LAUNCH_FLAG_DISABLE_STDIO"
value = "YES"
isEnabled = "NO">
</EnvironmentVariable>
<EnvironmentVariable
key = "LLDB_DEBUGSERVER_PATH"
value = "/tmp/debugserver"
isEnabled = "NO">
</EnvironmentVariable>
<EnvironmentVariable
key = "LLDB_DEBUGSERVER_LOG_FILE"
value = "/tmp/debugserver.txt"
Removed my specific binaires from the xcscheme. llvm-svn: 125603
2011-02-16 06:00:20 +08:00
isEnabled = "NO">
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
</EnvironmentVariable>
<EnvironmentVariable
key = "LLDB_DEBUGSERVER_LOG_FLAGS"
Made the EmulateInstruction class into a plug-in interface and moved the source files around into the places they need to go. llvm-svn: 124631
2011-02-01 08:04:43 +08:00
value = "0x802e0e"
Removed my specific binaires from the xcscheme. llvm-svn: 125603
2011-02-16 06:00:20 +08:00
isEnabled = "NO">
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
</EnvironmentVariable>
</EnvironmentVariables>
<AdditionalOptions>
Switching back to using std::tr1::shared_ptr. We originally switched away due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
2012-01-30 04:56:30 +08:00
<AdditionalOption
key = "MallocScribble"
value = ""
isEnabled = "YES">
</AdditionalOption>
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
</AdditionalOptions>
</LaunchAction>
<ProfileAction
Introduce a FormattersMatchData class which contains all the information that data formatters need in one place, and also allows for lazy computation of expensive chunks of information if need be This is a NFC commit that is essentially plumbing the new currency through the system llvm-svn: 249366
2015-10-06 09:02:47 +08:00
buildConfiguration = "Release"
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
shouldUseLaunchSchemeArgsEnv = "YES"
savedToolIdentifier = ""
useCustomWorkingDirectory = "NO"
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
ignoresPersistentStateOnLaunch = "YES"
debugDocumentVersioning = "YES">
Add the ability to tag one or more breakpoints with a name. These names can then be used in place of breakpoint id's or breakpoint id ranges in all the commands that operate on breakpoints. <rdar://problem/10103959> llvm-svn: 224392
2014-12-17 07:40:14 +08:00
<BuildableProductRunnable
runnableDebuggingMode = "0">
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
<BuildableReference
BuildableIdentifier = "primary"
BlueprintIdentifier = "26F5C26910F3D9A4009D5894"
BuildableName = "lldb"
BlueprintName = "lldb-tool"
ReferencedContainer = "container:lldb.xcodeproj">
</BuildableReference>
</BuildableProductRunnable>
Made the EmulateInstruction class into a plug-in interface and moved the source files around into the places they need to go. llvm-svn: 124631
2011-02-01 08:04:43 +08:00
<CommandLineArguments>
<CommandLineArgument
argument = "/Volumes/work/gclayton/Documents/src/attach/a.out"
Made lldb_private::ArchSpec contain much more than just an architecture. It now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
2011-02-16 05:59:32 +08:00
isEnabled = "NO">
</CommandLineArgument>
<CommandLineArgument
argument = "-a i386 /Volumes/work/gclayton/Documents/src/lldb/test/macosx/universal/testit"
Made the EmulateInstruction class into a plug-in interface and moved the source files around into the places they need to go. llvm-svn: 124631
2011-02-01 08:04:43 +08:00
isEnabled = "YES">
</CommandLineArgument>
</CommandLineArguments>
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
<EnvironmentVariables>
<EnvironmentVariable
key = "LLDB_LAUNCH_FLAG_DISABLE_ASLR"
value = "YES"
isEnabled = "NO">
</EnvironmentVariable>
<EnvironmentVariable
key = "LLDB_LAUNCH_FLAG_LAUNCH_IN_TTY"
value = "YES"
isEnabled = "NO">
</EnvironmentVariable>
<EnvironmentVariable
key = "LLDB_LAUNCH_FLAG_DISABLE_STDIO"
value = "YES"
isEnabled = "NO">
</EnvironmentVariable>
<EnvironmentVariable
key = "LLDB_DEBUGSERVER_PATH"
value = "/tmp/debugserver"
isEnabled = "NO">
</EnvironmentVariable>
<EnvironmentVariable
key = "LLDB_DEBUGSERVER_LOG_FILE"
value = "/tmp/debugserver.txt"
isEnabled = "YES">
</EnvironmentVariable>
<EnvironmentVariable
key = "LLDB_DEBUGSERVER_LOG_FLAGS"
Made the EmulateInstruction class into a plug-in interface and moved the source files around into the places they need to go. llvm-svn: 124631
2011-02-01 08:04:43 +08:00
value = "0x802e0e"
Adding a Xcode workspace for lldb. llvm-svn: 124416
2011-01-28 04:15:39 +08:00
isEnabled = "YES">
</EnvironmentVariable>
</EnvironmentVariables>
</ProfileAction>
<AnalyzeAction
buildConfiguration = "Debug">
</AnalyzeAction>
<ArchiveAction
buildConfiguration = "Release"
revealArchiveInOrganizer = "YES">
</ArchiveAction>
</Scheme>