2011-01-28 04:15:39 +08:00
|
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
|
|
|
<Scheme
|
2014-05-20 02:30:48 +08:00
|
|
|
LastUpgradeVersion = "0500"
|
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
|
|
|
version = "1.3">
|
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
|
2012-07-18 03:47:06 +08:00
|
|
|
selectedDebuggerIdentifier = "Xcode.DebuggerFoundation.Debugger.LLDB"
|
2014-07-09 02:09:58 +08:00
|
|
|
selectedLauncherIdentifier = "Xcode.DebuggerFoundation.Launcher.GDB"
|
2011-01-28 04:15:39 +08:00
|
|
|
shouldUseLaunchSchemeArgsEnv = "YES"
|
|
|
|
|
buildConfiguration = "Debug">
|
|
|
|
|
<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>
|
2011-02-01 08:04:43 +08:00
|
|
|
<CommandLineArguments>
|
|
|
|
|
<CommandLineArgument
|
|
|
|
|
argument = "/Volumes/work/gclayton/Documents/src/attach/a.out"
|
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"
|
2011-02-01 08:04:43 +08:00
|
|
|
isEnabled = "YES">
|
|
|
|
|
</CommandLineArgument>
|
|
|
|
|
</CommandLineArguments>
|
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"
|
2011-02-01 08:04:43 +08:00
|
|
|
value = "0x802e0e"
|
2011-01-28 04:15:39 +08:00
|
|
|
isEnabled = "YES">
|
|
|
|
|
</EnvironmentVariable>
|
|
|
|
|
</EnvironmentVariables>
|
|
|
|
|
</TestAction>
|
|
|
|
|
<LaunchAction
|
2012-03-08 07:05:14 +08:00
|
|
|
selectedDebuggerIdentifier = "Xcode.DebuggerFoundation.Debugger.LLDB"
|
|
|
|
|
selectedLauncherIdentifier = "Xcode.DebuggerFoundation.Launcher.LLDB"
|
2013-07-12 07:20:35 +08:00
|
|
|
launchStyle = "0"
|
2011-05-12 09:34:06 +08:00
|
|
|
useCustomWorkingDirectory = "NO"
|
2011-05-12 02:39:18 +08:00
|
|
|
customWorkingDirectory = "/Volumes/work/gclayton/Documents/devb/attach"
|
2013-03-12 09:19:42 +08:00
|
|
|
buildConfiguration = "Debug"
|
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"
|
|
|
|
|
allowLocationSimulation = "YES">
|
2012-04-07 08:00:41 +08:00
|
|
|
<BuildableProductRunnable>
|
2011-01-28 04:15:39 +08:00
|
|
|
<BuildableReference
|
|
|
|
|
BuildableIdentifier = "primary"
|
|
|
|
|
BlueprintIdentifier = "26F5C26910F3D9A4009D5894"
|
|
|
|
|
BuildableName = "lldb"
|
|
|
|
|
BlueprintName = "lldb-tool"
|
|
|
|
|
ReferencedContainer = "container:lldb.xcodeproj">
|
|
|
|
|
</BuildableReference>
|
2012-04-07 08:00:41 +08:00
|
|
|
</BuildableProductRunnable>
|
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"
|
2011-02-16 06:00:20 +08:00
|
|
|
isEnabled = "NO">
|
2011-01-28 04:15:39 +08:00
|
|
|
</EnvironmentVariable>
|
|
|
|
|
<EnvironmentVariable
|
|
|
|
|
key = "LLDB_DEBUGSERVER_LOG_FLAGS"
|
2011-02-01 08:04:43 +08:00
|
|
|
value = "0x802e0e"
|
2011-02-16 06:00:20 +08:00
|
|
|
isEnabled = "NO">
|
2011-01-28 04:15:39 +08:00
|
|
|
</EnvironmentVariable>
|
|
|
|
|
</EnvironmentVariables>
|
|
|
|
|
<AdditionalOptions>
|
2012-01-30 04:56:30 +08:00
|
|
|
<AdditionalOption
|
|
|
|
|
key = "MallocScribble"
|
|
|
|
|
value = ""
|
|
|
|
|
isEnabled = "YES">
|
|
|
|
|
</AdditionalOption>
|
2011-01-28 04:15:39 +08:00
|
|
|
</AdditionalOptions>
|
|
|
|
|
</LaunchAction>
|
|
|
|
|
<ProfileAction
|
|
|
|
|
shouldUseLaunchSchemeArgsEnv = "YES"
|
|
|
|
|
savedToolIdentifier = ""
|
|
|
|
|
useCustomWorkingDirectory = "NO"
|
2011-04-28 02:49:17 +08:00
|
|
|
buildConfiguration = "Release"
|
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">
|
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>
|
2011-02-01 08:04:43 +08:00
|
|
|
<CommandLineArguments>
|
|
|
|
|
<CommandLineArgument
|
|
|
|
|
argument = "/Volumes/work/gclayton/Documents/src/attach/a.out"
|
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"
|
2011-02-01 08:04:43 +08:00
|
|
|
isEnabled = "YES">
|
|
|
|
|
</CommandLineArgument>
|
|
|
|
|
</CommandLineArguments>
|
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"
|
2011-02-01 08:04:43 +08:00
|
|
|
value = "0x802e0e"
|
2011-01-28 04:15:39 +08:00
|
|
|
isEnabled = "YES">
|
|
|
|
|
</EnvironmentVariable>
|
|
|
|
|
</EnvironmentVariables>
|
|
|
|
|
</ProfileAction>
|
|
|
|
|
<AnalyzeAction
|
|
|
|
|
buildConfiguration = "Debug">
|
|
|
|
|
</AnalyzeAction>
|
|
|
|
|
<ArchiveAction
|
|
|
|
|
buildConfiguration = "Release"
|
|
|
|
|
revealArchiveInOrganizer = "YES">
|
|
|
|
|
</ArchiveAction>
|
|
|
|
|
</Scheme>
|