There were two problems associated with this radar:
1. "settings show target.source-map" failed to show the source-map after, for example,
"settings set target.source-map /Volumes/data/lldb/svn/trunk/test/source-manager /Volumes/data/lldb/svn/trunk/test/source-manager/hidden"
has been executed to set the source-map.
2. "list -n main" failed to display the source of the main() function after we properly set the source-map.
The first was fixed by adding the missing functionality to TargetInstanceSettings::GetInstanceSettingsValue (Target.cpp)
and updating the support files PathMappingList.h/.cpp; the second by modifying SourceManager.cpp to fix several places
with incorrect logic.
Also added a test case test_move_and_then_display_source() to TestSourceManager.py, which moves main.c to hidden/main.c,
sets target.source-map to perform the directory mapping, and then verifies that "list -n main" can still show the main()
function.
llvm-svn: 146422
We will return a valid range when possible and omit the "permissions" key
when the memory is not readable, writeable or executeable. This will help us
know the difference between an error back from this packet and unsupported,
from just "this address isn't in a valid region".
llvm-svn: 146394
<rdar://problem/10561406>
Stopped the SymbolFileDWARF::FindFunctions (...) from always calculating
the line table entry for all functions that were found. This can slow down
the expression parser if it ends up finding a bunch of matches. Fixed the
places that were relying on the line table entry being filled in.
Discovered a recursive stack blowout that happened when "main" didn't have
line info for it and there was no line information for "main"
llvm-svn: 146330
- Even if a frame isn't present, we always try
to use FindGlobalVariable to find variables.
Instead of using frame->TrackGlobalVariable()
to promote the VariableSP into a ValueObject,
we now simply use ValueObjectVariable.
- When requesting the value of a variable, we
allow returning of the "live version" of the
variable -- that is, the variable in the
target instead of a pointer to its freeze
dried version in LLDB -- even if there is no
process present.
llvm-svn: 146315
An assertion was firing when parsing types due to trying to complete parent
class decl contenxt types too often.
Also, relax where "dsymutil" binary can come from in the Makefile.rules.
llvm-svn: 146310
hard to ensure it doesn't get invalidated out from under us. Instead look it up from the ThreadID
and StackID when asked for it.
<rdar://problem/10554409>
llvm-svn: 146309
that if we prefer the current compile unit, followed by any compile units that
already had their DIEs parsed, followed by the rest of the matches, that we
might save some memory. This turned out not to help much. The code is commented
out, but I want to check it in so I don't lose the code in case it could help
later.
Added the ability to efficiently find the objective C class implementation
when using the new .apple_types acclerator tables with the type flags. If the
type flags are not available, we default back to what we were doing before.
llvm-svn: 146250
PlatformDarwin.cpp -- call it from both PlatformRemoteiOS.cpp
and the native process PlatformDarwin.cpp when running on an arm
system.
Bump lldb version number to 94.
llvm-svn: 146249
that got hit, and first check the condition, and if that location's condition says we should stop, then we
run the callback. In the end if any location's condition and callback say we should stop, then we stop.
llvm-svn: 146242
translation unit has a interface for a class "Bar" that contains hidden ivars
in the implementation and we make sure we can see these hidden ivars. We also
test the case where we stop in translation unit that contains the
implementation first. So the test runs two tests:
1 - run and stop where we have an interface, run to main and print and make
sure we find the hidden ivar
2 - run and stop where we have an implementation, run to main and print and make
sure we find the hidden ivar
llvm-svn: 146216
in the context in which it was originally found, the
expression parser now goes hunting for it in all modules
(in the appropriate namespace, if applicable). This means
that forward-declared types that exist in another shared
library will now be resolved correctly.
Added a test case to cover this. The test case also tests
"frame variable," which does not have this functionality
yet.
llvm-svn: 146204
pointer to make the result of an expression. LLDB now
dumps the ivars of the Objective-C object and all of
its parents. This just required fixing a bug where we
didn't distinguish between Objective-C object pointers
and regular C-style pointers.
Also added a testcase to verify that this continues to
work.
llvm-svn: 146164
that is in a class from the expression parser, and it was causing an
assertion. There is now a function that will correctly resolve a type
even if it is in a class.
llvm-svn: 146141
take a SymbolFile reference and a lldb::user_id_t and be used in objects
which represent things in debug symbols that have types where we don't need
to know the true type yet, such as in lldb_private::Variable objects. This
allows us to defer resolving the type until something is used. More specifically
this allows us to get 1000 local variables from the current function, and if
the user types "frame variable argc", we end up _only_ resolving the type for
"argc" and not for the 999 other local variables. We can expand the use of this
as needed in the future.
Modified the DWARFMappedHash class to be able to read the HashData that has
more than just the DIE offset. It currently will read the atoms in the header
definition and read the data correctly. Currently only the DIE offset and
type flags are supported. This is needed for adding type flags to the
.apple_types hash accelerator tables.
Fixed a assertion crash that would happen if we have a variable that had a
DW_AT_const_value instead of a location where "location.LocationContains_DW_OP_addr()"
would end up asserting when it tried to parse the variable location as a
DWARF opcode list.
Decreased the amount of memory that LLDB would use when evaluating an expression
by 3x - 4x for clang. There was a place in the namespace lookup code that was
parsing all namespaces with a certain name in a DWARF file instead of stopping
when it found the first match. This was causing all of the compile units with
a matching namespace to get parsed into memory and causing unnecessary memory
bloat.
Improved "Target::EvaluateExpression(...)" to not try and find a variable
when the expression contains characters that would certainly cause an expression
to need to be evaluated by the debugger.
llvm-svn: 146130
for now to fix testcases. Once we have a valid use
for the function information (i.e., once properties
returning UnknownAnyTy are allowed, once we read
return type information from the runtime, among
other uses) I will re-enable this.
llvm-svn: 146129
symbols. Now we find the correct method.
Unfortunately we don't get the superclass from the
runtime yet so the method doesn't import correctly
(and I added a check to make sure that doesn't hurt
us) but once we get that information right we will
report methods correctly to the parser as well.
Getting superclass information requires a common AST
context for all Objective-C runtime information,
meaning that the superclass and the subclass are in
the same AST context in all cases. That is the next
thing that needs to be done here.
llvm-svn: 146089
for use in the benchmark against lldb's disassembly speed. Note that the lldb
executable path can already be specified using the LLDB_EXEC env variable.
rdar://problem/7511194
llvm-svn: 146050
from symbols more accessible, I have added a second
map to the ClangASTImporter: the ObjCInterfaceMetaMap.
This map keeps track of all type definitions found for
a particular Objective-C interface, allowing the
ClangASTSource to refer to all possible sources when
looking for method definitions.
There is a bug in lookup that I still need to figure out,
but after that we should be able to report full method
information for Objective-C classes shown in symbols.
Also fixed some errors I ran into when enabling the maps
for the persistent type store. The persistent type store
previously did not use the ClangASTImporter to import
types, instead using ASTImporters that got allocated each
time a type needed copying. To support the requirements
of the persistent type store -- namely, that types must be
copied, completed, and then completely severed from their
origin in the parser's AST context (which will go away) --
I added a new function called DeportType which severs all
these connections.
llvm-svn: 145914
methods. The Clang dump is now much more verbose,
but when somebody types "target modules lookup -t"
that is typically what they're looking for.
llvm-svn: 145892
and CompleteTagDeclarationDefinition() on Objective-C
interfaces populated by SymbolFileSymtab::FindTypes(),
we should mark the interface as forward-declared when
we create it.
llvm-svn: 145825
and fixes we did. Now that objective C classes are represented by symbols with
their own type, there were a few more places in the objective C code that needed
to be fixed when searching for dynamic types.
Cleaned up the objective C runtime plug-in a bit to not keep having to create
constant strings and make one less memory access when we find an "isa" in the
objective C cache.
llvm-svn: 145799
add them to a fast lookup map. lldb_private::Symtab now export the following
public typedefs:
namespace lldb_private {
class Symtab {
typedef std::vector<uint32_t> IndexCollection;
typedef UniqueCStringMap<uint32_t> NameToIndexMap;
};
}
Clients can then find symbols by name and or type and end up with a
Symtab::IndexCollection that is filled with indexes. These indexes can then
be put into a name to index lookup map and control if the mangled and
demangled names get added to the map:
bool add_demangled = true;
bool add_mangled = true;
Symtab::NameToIndexMap name_to_index;
symtab->AppendSymbolNamesToMap (indexes, add_demangled, add_mangled, name_to_index).
This can be repeated as many times as needed to get a lookup table that
you are happy with, and then this can be sorted:
name_to_index.Sort();
Now name lookups can be done using a subset of the symbols you extracted from
the symbol table. This is currently being used to extract objective C types
from object files when there is no debug info in SymbolFileSymtab.
Cleaned up how the objective C types were being vended to be more efficient
and fixed some errors in the regular expression that was being used.
llvm-svn: 145777
class. The thing with Objective C classes is the debug info might have a
definition that isn't just a forward decl, but it is incomplete. So we need to
look and see if we can find the complete definition and avoid recursing a lot
due to the fact that our accelerator tables will have many versions of the
type, but only one complete one. We might not also have the complete type
and we need to deal with this correctly.
llvm-svn: 145759
Objective-C, making symbol lookups for various raw
Objective-C symbols work correctly. The IR interpreter
makes these lookups because Clang has emitted raw
symbol references for ivars and classes.
Also improved performance in SymbolFiles, caching the
result of asking for SymbolFile abilities.
llvm-svn: 145758
for all our external AST sources that lets us associate
arbitrary flags with the types we put into the AST
contexts. Also added an API on ClangASTContext that
allows access to these flags given only an ASTContext
and a type.
Because we don't have access to RTTI, and because at
some point in the future we might encounter external
AST sources that we didn't make (so they don't subclass
ClangExternalASTSourceCommon) I added a magic number
that we check before doing anything else, so that we
can catch that problem as soon as it appears.
llvm-svn: 145748
object file can correctly make these symbols which will abstract us from the
file format and ABI and we can then ask for the objective C class symbol for
a class and find out which object file it was defined in.
llvm-svn: 145744
the function it is being asked to step through, so that even if we get the trampoline
target wrong (for instance) we will still not lose control.
The other fix here is to tighten up the handling of the case where the current plan
doesn't explain the stop, but a plan above us does. In that case, if the plan that
does explain the stop says it is done, we need to clean up the plans below it and
continue on with our processing.
llvm-svn: 145740
Fixed an issue where if we have the DWARF equivalent of:
struct foo;
class foo { ... };
Or vice versa, we wouldn't be able to find the complete type. Since many
compilers allow forward declarations to have struct and definitions to have
class, we need to be able to deal with both cases. This commit fixes this in
the DWARF parser.
llvm-svn: 145733
to use ConstStrings. The const char*s were assumed to
be from ConstStrings before, but since storing a full-on
ConstString is no more expensive than storing a const
char* it makes better sense to enforce uniqueness with
the type checker.
llvm-svn: 145688
Fixed templates with NonTypeTemplateParmDecl objects. For example:
template <unsigned N>
....
This fixes SmallVector and all of the other classes that have template params
that are non types.
llvm-svn: 145667
will allow us to represent a process/thread ID using a pointer for the OS
plug-ins where they might want to represent the process or thread ID using
the address of the process or thread structure.
llvm-svn: 145644
in the face of failures to import types, since blithely
passing on NULL types can sometimes lead to trouble.
Also eliminated a use of getAs and replaced it with
dyn_cast, which is more robust.
llvm-svn: 145628
enhancements. With these enhancements, the return values
of Objective-C methods with unknown return types can be
implicitly cast to id for the purpose of making method
calls.
So what would have required this:
(int)[(id)[ClassWithNoDebugInfo methodReturningObject] methodReturningInt]
can now be written as:
(int)[[ClassWithNoDebugInfo methodReturningObject] methodReturningInt]
llvm-svn: 145567
robust:
- Now a client can specify what kind of symbols
are needed; notably, this allows looking up
Objective-C class symbols specifically.
- In the class of symbols being looked up, if
one is non-NULL and others are NULL, LLDB now
prefers the non-NULL one.
llvm-svn: 145554
ClangASTSource::~ClangASTSource() was calling
ClangASTContext *scratch_clang_ast_context = m_target->GetScratchClangASTContext();
which had the side effect of deleting this very ClangASTSource instance. Not good.
Change it to
// We are in the process of destruction, don't create clang ast context on demand
// by passing false to Target::GetScratchClangASTContext(create_on_demand).
ClangASTContext *scratch_clang_ast_context = m_target->GetScratchClangASTContext(false);
The Target::GetScratchClangASTContext(bool create_on_demand=true) has a new signature.
llvm-svn: 145537
to find Objective-C class types by looking in the
symbol tables for the individual object files.
I did this as follows:
- I added code to SymbolFileSymtab that vends
Clang types for symbols matching the pattern
"_OBJC_CLASS_$_NSMyClassName," making them
appear as Objective-C classes. This only occurs
in modules that do not have debug information,
since otherwise SymbolFileDWARF would be in
charge of looking up types.
- I made a new SymbolVendor subclass for the
Apple Objective-C runtime that is in charge of
making global lookups of Objective-C types. It
currently just sends out type lookup requests to
the appropriate SymbolFiles, but in the future we
will probably extend it to query the runtime more
completely.
I also modified a testcase whose behavior is changed
by the fact that we now actually return an Objective-C
type for __NSCFString.
llvm-svn: 145526
Fix wrong test logic in test_modules_search_paths(). Add additional exercising of 'target modules search-paths list/query".
There is a reproducible crash if 'target modules search-paths clear' is exercised during test teardown.
So we currently comment out the stmt as follows:
# Add teardown hook to clear image-search-paths after the test.
# rdar://problem/10501020
# Uncomment the following to reproduce 10501020.
#self.addTearDownHook(lambda: self.runCmd("target modules search-paths clear"))
llvm-svn: 145466
Fixed an issue where if we are debugging on a remote platform and set a
platform path for our executable, it was not being honored by the new
launch functions that used the ProcessLaunchInfo.
llvm-svn: 145371
as well as attached a new priority description as to why and when you would
want to implement each packet.
Also documented the additions we have made to the stop reply packet and why
the extra information is necessary.
llvm-svn: 145357
management of what allocations remain after an
expression finishes executing. This saves around
2.5KiB per expression for simple expressions.
llvm-svn: 145342
so that we can do Python scripting like this:
target = self.dbg.CreateTarget(self.exe)
self.dbg.SetAsync(True)
process = target.LaunchSimple(None, None, os.getcwd())
process.PutSTDIN("Line 1 Entered.\n")
process.PutSTDIN("Line 2 Entered.\n")
process.PutSTDIN("Line 3 Entered.\n")
Add TestProcessIO.py to exercise the process IO API: PutSTDIN()/GetSTDOUT()/GetSTDERR().
llvm-svn: 145282
to launch a process for debugging. Since this isn't supported on all platforms,
we need to do what we used to do if this isn't supported. I added:
bool
Platform::CanDebugProcess ();
This will get checked before trying to launch a process for debugging and then
fall back to launching the process through the current host debugger. This
should solve the issue for linux and keep the platform code clean.
Centralized logging code for logging errors, warnings and logs when reporting
things for modules or symbol files. Both lldb_private::Module and
lldb_private::SymbolFile now have the following member functions:
void
LogMessage (Log *log, const char *format, ...);
void
ReportWarning (const char *format, ...);
void
ReportError (const char *format, ...);
These will all output the module name and object (if any) such as:
"error: lldb.so ...."
"warning: my_archive.a(foo.o) ...."
This will keep the output consistent and stop a lot of logging calls from
having to try and output all of the information that uniquely identifies
a module or symbol file. Many places in the code were grabbing the path to the
object file manually and if the module represented a .o file in an archive, we
would see log messages like:
error: foo.a - some error happened
llvm-svn: 145219
to 30% of memory. The size doubling was killing us and we ended up with up to
just under 50% of empty capacity. Cleaning this up saves us a ton of memory.
llvm-svn: 145086
Fixed an issue with the options for memory read where --count couldn't be used
with the --binary option when writing data to a file.
Also removed the GDB format option from the --binary version of memory read.
llvm-svn: 145067
something like "display/4i $pc" (or something like this). With LLDB we already
were showing 3 lines of source before and 3 lines of source after the current
source line when showing a stop context. We now improve this by allowing the
user to control the number of lines with the new "stop-line-count-before" and
"stop-line-count-after" settings. Also, there is a new setting for how many
disassembly lines to show: "stop-disassembly-count". This will control how many
source lines are shown when there is no source or when we have no source line
info.
settings set stop-line-count-before 3
settings set stop-line-count-after 3
settings set stop-disassembly-count 4
settings set stop-disassembly-display no-source
The default values are set as shown above and allow 3 lines of source before
and after (what we used to do) the current stop location, and will display 4
lines of disassembly if the source is not available or if we have no debug
info. If both "stop-source-context-before" and "stop-source-context-after" are
set to zero, this will disable showing any source when stopped. The
"stop-disassembly-display" setting is an enumeration that allows you to control
when to display disassembly. It has 3 possible values:
"never" - never show disassembly no matter what
"no-source" - only show disassembly when there is no source line info or the source files are missing
"always" - always show disassembly.
llvm-svn: 145050
several patches. These patches fix a problem
where templated types were not being completed the
first time they were used, and fix a variety of
minor issues I discovered while fixing that problem.
One of the previous local patches was resolved in
the most recent Clang, so I removed it. The others
will be removed in due course.
llvm-svn: 144984
1 - the DIE collections no longer have the NULL tags which saves up to 25%
of the memory on typical C++ code
2 - faster parsing by not having to run the SetDIERelations() function anymore
it is done when parsing the DWARF very efficiently.
llvm-svn: 144983
the name of the PLT entry. This solution assumes a naming convention agreed upon by us and the system folks,
and isn't general. The general solution requires actually finding & calling the resolver function if it
hasn't been called yet. That's more tricky.
llvm-svn: 144981
from a process and hooked it up to the new packet that was recently added
to our GDB remote executable named debugserver. Now Process has the following
new calls:
virtual Error
Process::GetMemoryRegionInfo (lldb::addr_t load_addr, MemoryRegionInfo &range_info);
virtual uint32_t
GetLoadAddressPermissions (lldb::addr_t load_addr);
Only the first one needs to be implemented by subclasses that can add this
support.
Cleaned up the way the new packet was implemented in debugserver to be more
useful as an API inside debugserver. Also found an error where finding a region
for an address actually will pick up the next region that follows the address
in the query so we also need ot make sure that the address we requested the
region for falls into the region that gets returned.
llvm-svn: 144976
we say that the vectors of DWARFDebugInfoEntry objects were the highest on the
the list.
With these changes we cut our memory usage by 40%!!! I did this by reducing
the size of the DWARFDebugInfoEntry from a previous:
uint32_t offset
uint32_t parent_idx
uint32_t sibling_idx
Abbrev * abbrev_ptr
which was 20 bytes, but rounded up to 24 bytes due to alignment. Now we have:
uint32_t offset
uint32_t parent_idx
uint32_t sibling_idx
uint32_t abbr_idx:15, // 32767 possible abbreviation codes
has_children:1, // 0 = no children, 1 = has children
tag:16; // DW_TAG_XXX value
This gets us down to 16 bytes per DIE. I tested some VERY large DWARF files
(900MB) and found there were only ~700 unique abbreviations, so 32767 should
be enough for any sane compiler. If it isn't there are built in assertions
that will fire off and tell us.
llvm-svn: 144975
to allow variables in the persistent variable store to know
how to complete themselves from debug information. That
fixes a variety of bugs during dematerialization of
expression results and also makes persistent variable and
result variables ($foo, $4, ...) more useful.
I have also added logging improvements that make it much
easier to figure out how types are moving from place to
place, and made some checking a little more aggressive.
The commit includes patches to Clang which are currently being
integrated into Clang proper; once these fixes are in Clang
top-of-tree, these patches will be removed. The patches don't
fix API; rather, they fix some internal bugs in Clang's
ASTImporter that were exposed when LLDB was moving types from
place to place multiple times.
llvm-svn: 144969
Use this option with care as you would need to build the inferior(s) by hand
and build the executable(s) with the correct name(s). This option can be used
with '-# n' to stress test certain test cases for n number of times.
An example:
[11:55:11] johnny:/Volumes/data/lldb/svn/trunk/test/python_api/value $ ls
Makefile TestValueAPI.pyc linked_list
TestValueAPI.py change_values main.c
[11:55:14] johnny:/Volumes/data/lldb/svn/trunk/test/python_api/value $ make EXE=test_with_dsym
clang -gdwarf-2 -O0 -arch x86_64 -c -o main.o main.c
clang -gdwarf-2 -O0 -arch x86_64 main.o -o "test_with_dsym"
/usr/bin/dsymutil -o "test_with_dsym.dSYM" "test_with_dsym"
[11:55:20] johnny:/Volumes/data/lldb/svn/trunk/test/python_api/value $ cd ../..
[11:55:24] johnny:/Volumes/data/lldb/svn/trunk/test $ ./dotest.py -v -# 10 -S -f ValueAPITestCase.test_with_dsym
LLDB build dir: /Volumes/data/lldb/svn/trunk/build/Debug
LLDB-89
Path: /Volumes/data/lldb/svn/trunk
URL: https://johnny@llvm.org/svn/llvm-project/lldb/trunk
Repository Root: https://johnny@llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 144914
Node Kind: directory
Schedule: normal
Last Changed Author: gclayton
Last Changed Rev: 144911
Last Changed Date: 2011-11-17 09:22:31 -0800 (Thu, 17 Nov 2011)
Session logs for test failures/errors/unexpected successes will go into directory '2011-11-17-11_55_29'
Command invoked: python ./dotest.py -v -# 10 -S -f ValueAPITestCase.test_with_dsym
----------------------------------------------------------------------
Collected 1 test
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
Exercise some SBValue APIs. ... ok
----------------------------------------------------------------------
Ran 1 test in 1.163s
OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
Exercise some SBValue APIs. ... ok
----------------------------------------------------------------------
Ran 1 test in 0.200s
OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
Exercise some SBValue APIs. ... ok
----------------------------------------------------------------------
Ran 1 test in 0.198s
OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
Exercise some SBValue APIs. ... ok
----------------------------------------------------------------------
Ran 1 test in 0.199s
OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
Exercise some SBValue APIs. ... ok
----------------------------------------------------------------------
Ran 1 test in 0.239s
OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
Exercise some SBValue APIs. ... ok
----------------------------------------------------------------------
Ran 1 test in 1.215s
OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
Exercise some SBValue APIs. ... ok
----------------------------------------------------------------------
Ran 1 test in 0.105s
OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
Exercise some SBValue APIs. ... ok
----------------------------------------------------------------------
Ran 1 test in 0.098s
OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
Exercise some SBValue APIs. ... ok
----------------------------------------------------------------------
Ran 1 test in 0.195s
OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
Exercise some SBValue APIs. ... ok
----------------------------------------------------------------------
Ran 1 test in 1.197s
OK
[11:55:34] johnny:/Volumes/data/lldb/svn/trunk/test $
llvm-svn: 144919
turned out to be unitialized data in the ProcessLaunchInfo default constructor.
Turning on MallocScribble in the environment helped track this down.
When we launch and attach using the host layer, we now inform the process that
it shouldn't detach when by calling an accessor.
llvm-svn: 144882
the thread specific data and were destroying the thread specfic data more
than once.
Also added the ability to ask a lldb::StateType if it is stopped with an
additional paramter of "must_exist" which means that the state must be a
stopped state for a process that still exists. This means that eStateExited
and eStateUnloaded will no longer return true if "must_exist" is set to true.
llvm-svn: 144875
completion information between different AST
contexts. It works like this:
- If a Decl is imported from a context that
has completion metadata, then that Decl
is associated with the same completion
information (possibly none) as the Decl
it was imported from.
- If a Decl is imported from a context that
does not have completion metadata, then it
is marked as completable by consulting the
Decl and context it was imported from.
llvm-svn: 144838
for each AST context it knows about in a single
object. This makes it faster to look up the
appropriate ASTImpoter for a given ASTContext
pair and also makes it much easier to delete all
metadata for a given AST context.
In the future, this fix will allow the
ClangASTImporter to propagate completion
information between the metadata for different
AST contexts as its minions move AST objects
around.
llvm-svn: 144835
rather than individually on behalf of each
ASTContext. This allows the ASTImporter to know
about all containers of types, which will let it
be smarter about forwarding information about
type origins. That means that the following
sequence of steps will be possible (after a few
more changes):
- Import a type from a Module's ASTContext into
an expression parser ASTContext, tracking its
origin information -- this works now.
- Because the result of the expression uses that
type, import it from the expression parser
ASTContext into the Target's scratch AST
context, forwarding the origin information --
this needs to be added.
- For a later expression that uses the result,
import the type from the Target's scratch AST
context, still forwarding origin information
-- this also needs to be added.
- Use the intact origin information to complete
the type as needed -- this works now if the
origin information is present.
To this end, I made the following changes:
- ASTImporter top-level copy functions now
require both a source and a destination AST
context parameter.
- The ASTImporter now knows how to purge
records related to an ASTContext that is
going away.
- The Target now owns and creates the ASTImporter
whenever the main executable changes or (in the
absence of a main executable) on demand.
llvm-svn: 144802
After recent changes we weren't reaping child processes resulting in many
zombie processes.
This was fixed by adding more settings to the ProcessLaunchOptions class
that allow clients to specify a callback function and baton to be notified
when their process dies. If one is not supplied a default callback will be
used that "does the right thing".
Cleaned up a race condition in the ProcessGDBRemote class that would attempt
to monitor when debugserver died.
Added an extra boolean to the process monitor callbacks that indicate if a
process exited or not. If your process exited with a zero exit status and no
signal, both items could be zero.
Modified the process monitor functions to not require a callback function
in order to reap the child process.
llvm-svn: 144780
NULL-terminated C string to store the contents
of the expression prefix file. This meant that
expressions, when printing the contents of the
prefix into the expression's text, would
invariably put in bad data after the end of the
expression.
Now, instead, we store the prefix contents in a
std::string, which handles null-termination
correctly.
llvm-svn: 144760
types. First, I added handling for the memset intrinsic
in the IR, which is used to zero out the returned struct.
Second, I fixed the object-checking instrumentation
to objc_msgSend_stret, and generally tightened up how
the object-checking functions get inserted.
llvm-svn: 144741
info for us to attach by pid, or by name and will also allow us to eventually
do a lot more powerful attaches. If you look at the options for the "platform
process list" command, there are many options which we should be able to
specify. This will allow us to do things like "attach to a process named 'tcsh'
that has a parent process ID of 123", or "attach to a process named 'x' which
has an effective user ID of 345".
I finished up the --shell implementation so that it can be used without the
--tty option in "process launch". The "--shell" option now can take an
optional argument which is the path to the shell to use (or a partial name
like "sh" which we will find using the current PATH environment variable).
Modified the Process::Attach to use the new ProcessAttachInfo as the sole
argument and centralized a lot of code that was in the "process attach"
Execute function so that everyone can take advantage of the powerful new
attach functionality.
llvm-svn: 144615
of problems with Objective-C object completion. To go
along with the LLVM/Clang-side fixes, we have a variety
of Objective-C improvements.
Fixes include:
- It is now possible to run expressions when stopped in
an Objective-C class method and have "self" act just
like "self" would act in the class method itself (i.e.,
[self classMethod] works without casting the return
type if debug info is present). To accomplish this,
the expression masquerades as a class method added by
a category.
- Objective-C objects can now provide methods and
properties and methods to Clang on demand (i.e., the
ASTImporter sets hasExternalVisibleDecls on Objective-C
interface objects).
- Objective-C built-in types, which had long been a bone
of contention (should we be using "id"? "id*"?), are
now fetched correctly using accessor functions on
ClangASTContext. We inhibit searches for them in the
debug information.
There are also a variety of logging fixes, and I made two
changes to the test suite:
- Enabled a test case for Objective-C properties in the
current translation unit.
- Added a test case for calling Objective-C class methods
when stopped in a class method.
llvm-svn: 144607
Fixed an issues with the SBType and SBTypeMember classes:
- Fixed SBType to be able to dump itself from python
- Fixed SBType::GetNumberOfFields() to return the correct value for objective C interfaces
- Fixed SBTypeMember to be able to dump itself from python
- Fixed the SBTypeMember ability to get a field offset in bytes (the value
being returned was wrong)
- Added the SBTypeMember ability to get a field offset in bits
Cleaned up a lot of the Stream usage in the SB API files.
llvm-svn: 144493
This is the actual fix for the above radar where global variables that weren't
initialized were not being shown correctly when leaving the DWARF in the .o
files. Global variables that aren't intialized have symbols in the .o files
that specify they are undefined and external to the .o file, yet document the
size of the variable. This allows the compiler to emit a single copy, but makes
it harder for our DWARF in .o files with the executable having a debug map
because the symbol for the global in the .o file doesn't exist in a section
that we can assign a fixed up linked address to, and also the DWARF contains
an invalid address in the "DW_OP_addr" location (always zero). This means that
the DWARF is incorrect and actually maps all such global varaibles to the
first file address in the .o file which is usually the first function. So we
can fix this in either of two ways: make a new fake section in the .o file
so that we have a file address in the .o file that we can relink, or fix the
the variable as it is created in the .o file DWARF parser and actually give it
the file address from the executable. Each variable contains a
SymbolContextScope, or a single pointer that helps us to recreate where the
variables came from (which module, file, function, etc). This context helps
us to resolve any file addresses that might be in the location description of
the variable by pointing us to which file the file address comes from, so we
can just replace the SymbolContextScope and also fix up the location, which we
would have had to do for the other case as well, and update the file address.
Now globals display correctly.
The above changes made it possible to determine if a variable is a global
or static variable when parsing DWARF. The DWARF emits a DW_TAG_variable tag
for each variable (local, global, or static), yet DWARF provides no way for
us to classify these variables into these categories. We can now detect when
a variable has a simple address expressions as its location and this will help
us classify these correctly.
While making the above changes I also noticed that we had two symbol types:
eSymbolTypeExtern and eSymbolTypeUndefined which mean essentially the same
thing: the symbol is not defined in the current object file. Symbol objects
also have a bit that specifies if a symbol is externally visible, so I got
rid of the eSymbolTypeExtern symbol type and moved all code locations that
used it to use the eSymbolTypeUndefined type.
llvm-svn: 144489
the --tty option. So you can now get shell expansion and file redirection:
(lldb) process launch --tty --shell -- *.jpg < in.txt > out.txt
Again, the "--tty" is mandatory for now until we hook this up to other
functions. The shell is also currently hard coded to "/bin/bash" and not the
"SHELL" variable. "/bin/tcsh" was causing problems which I need to dig into.
llvm-svn: 144443
interfaces. This allows us to pull in Objective-C
method types on demand, which is also now implemented.
Also added a minor fix to prevent multiple-definition
errors for "Class" and "id".
llvm-svn: 144405
problem is that we had a bitfield that kept
track of what had been found so far, and inhibited
searches when the local variable bit was set.
This bitfield was not being initialized correctly.
llvm-svn: 144400
the argument description in the command name could cause a command
alias to crash, e.g.
command alias zzz target stop-hook delete 1
because the "name" is used to re-fetch the exact CommandObject when
adding the final arg.
<rdar://problem/10423753>
llvm-svn: 144330
string to avoid possible later crashes.
Modified the locations that do set the crash description to NULL out the
string when they are done doing their tasks.
llvm-svn: 144297
Fixed an issue where if you had an initialized global variable, we would not
link it up correctly in the debug info if the .o file had the symbols as
UNDF + EXT (undefined external). We now properly link the globals.
llvm-svn: 144259
lookups for Objective-C methods by selector.
Right now all it does is print log information.
Also improved the logging for imported TagDecls
to indicate whether or not the definition for
the imported TagDecl is complete.
llvm-svn: 144203
Add a more general purpose qMemoryRegionInfo packet which can
describe various attributes about a memory region. Currently it
will return the start address, size, and permissions (read, write,
executable) for the memory region. It may be possible to add
additional attributes in the future such as whether the region is
designated as stack memory or jitted code a la vmmap.
I still haven't implemented the lldb side of the code to use this
packet yet so there may be unexpected behavior - but the basic implementation looks
about right. I'll hook it up to lldb soon and fix any problems that crop up.
llvm-svn: 144175
whether a given address is in an executable region of memory or
not. I haven't written the lldb side that will use this packet it
hasn't been tested yet but it's a simple enough bit of code.
I want to have this feature available for the unwinder code. When
we're stopped at an address with no valid symbol context, there are
a number of questions I'd like to ask --
is the current pc value in an executable region (e.g. did they
jump to unallocated/unexecutable memory? we know how to unwind
from here if so.)
Is the stack pointer or the frame pointer the correct register
to use to find the caller's saved pc value?
Once we're past the first frame we can trust things like eh_frame
and ABI unwind schemes but the first frame is challenging and having
a way to check potential addresses to see if they're executable or
not would help narrow down the possibilities a lot.
llvm-svn: 144074
doesn't handle bitfields in eFormatChar's correctly, only eFormatUnsigned.
Fix DataExtractor::Dump to dump the bitfield eFormatChars correctly.
llvm-svn: 144069
be in the target. All of the environment, args, stdin/out/err files, etc have
all been moved. Also re-enabled the ability to launch a process in a separate
terminal on MacOSX.
llvm-svn: 144061
which will in the future allow expressions to be
compiled as C, C++, and Objective-C instead of the
current default Objective-C++. This feature requires
some additional support from Clang -- specifically, it
requires reference types in the parser regardless of
language -- so it is not yet exposed to the user.
llvm-svn: 144042
dated 2010-21-15. The test started failure recently probably due to work done on the command parsing.
Anyway, the specific test sequence is invalid and is fixed now.
llvm-svn: 144039
a) adds a new --synchronicity (-s) setting for "command script add" that allows the user to decide if scripted commands should run synchronously or asynchronously (which can make a difference in how events are handled)
b) clears up several error messages
c) adds a new --allow-reload (-r) setting for "command script import" that allows the user to reload a module even if it has already been imported before
d) allows filename completion for "command script import" (much like what happens for "target create")
e) prevents "command script add" from replacing built-in commands with scripted commands
f) changes AddUserCommand() to take an std::string instead of a const char* (for performance reasons)
plus, it fixes an issue in "type summary add" command handling which caused several test suite errors
llvm-svn: 144035
Joel Dillon that fixed 64 debugging for Linux.
I also added a patch to fix up the ProcessLinux::DoLaunch() to be up to date.
I wasn't able to verify it compiles, but it should b really close.
llvm-svn: 143772
C++ vtables, fixing a record layout problem in the
expression parser.
Also fixed various problems with the generation
and unpacking of llvm.zip given our new better
handling of multiple architectures in the LLVM
build.
(And added a log message that will hopefully catch
record layout problems in the future.)
llvm-svn: 143741
we often nuke our "build" folder so we can do clean builds. This way if you
are building your own LLVM you won't have to rebuild LLVM when you do remove
your build folder. The new location for the LLVM build is:
lldb/llvm-build
llvm-svn: 143713
- 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 into
arch specific directories and never get merged into universal binaries as this
was causing issues where you would have to go and delete the file if you wanted
to build an extra architecture slice.
llvm-svn: 143678
target is stopped in a C++ or Objective-C method
but the "self" pointer's valid range actually
doesn't cover the current location. Before, that
was confusing Clang to the point where it crashed;
now, we sanity-check and fall back to pretending
we're in a C function if "self" or "this" isn't
available.
llvm-svn: 143676
Greps and returns the first svn log entry containing a line matching the regular
expression pattern passed as the only arg.
Example:
svn log -v | grep-svn-log.py '^ D.+why_are_you_missing.h$'
llvm-svn: 143671
on internal only (public API hasn't changed) to simplify the paramter list
to the launch calls down into just one argument. Also all of the argument,
envronment and stdio things are now handled in a much more centralized fashion.
llvm-svn: 143656
IRInterpreter to get the value, not the location,
of references. The location of a reference has
type T&&, which is meaningless to Clang.
llvm-svn: 143592
allows us to set __attribute__ ((used)) on expressions
that masquerade as methods. When we are stopped in
classes in anonymous namespaces, this fix (and enabling
__attribute__ ((used)) on the method) will allow
expressions to run.
llvm-svn: 143560
Fixed an issue where the DWARF might mention that a class has a constructor
(default, copy or move), destructor, or an assignment operator (copy or move)
and it might not have an actual implementation in your code. Then you try and
use this struct or class in an expression and the JIT would ask for the
address of these methods that were in the declaration, yet there are none.
We now "do the right thing" for trivial ctors, dtors and assignment operators
by telling the methods that they are are defaulted and trivial, and clang will
then just do all of the work with builtins!
llvm-svn: 143528
generated special member functions (constructors,
destructors, etc.) for classes that don't really have
them. We needed to mark these as artificial to reflect
the debug information; this bug does that for
constructors and destructors.
The "etc." case (certain assignment operators, mostly)
remains to be fixed.
llvm-svn: 143526
correctly, and added a testcase to check that it works.
The main problem here is that Objective-C class method
selectors are external references stored in a special
data structure in the LLVM IR module for an expression.
I just had to extract them and ensure that the real
class object locations were properly resolved.
llvm-svn: 143520
method as __attribute__ ((used)) when adding it to a
class. This functionality is useful when stopped in
anonymous namespaces: expressions attached to classes
in anonymous namespaces are typically elided by Clang's
CodeGen because they have no namespaces are intended
not to be externally visible. __attribute__ ((used))
forces CodeGen to emit the function.
Right now, __attribute__ ((used)) causes the JIT not to
emit the function, so we're not enabling it until we
fix that.
llvm-svn: 143469
RegisterContextLLDBs it contains.
Previously RegisterContextLLDB objects had a pointer to their "next"
frame down the stack. e.g. stack starts at frame 0; frame 3 has a
pointer to frame 2. This is used to retreive callee saved register
values. When debugging an inferior that has blown out its own stack,
however, this could result in lldb blowing out its own stack while
recursing down to retrieve register values.
RegisterContextLLDB no longer has a pointer to its next frame; it
has a reference to the UnwindLLDB which contains it. When it needs
to retrieve a reg value, it asks the UnwindLLDB for that reg value
and UnwindLLDB iterates through the frames until it finds a location.
llvm-svn: 143423
"object borked"... Also made the error when the checker fails reflect this fact rather than
report a crash at 0x0.
Also a little cleanup:
- StopInfoMachException had a redundant copy of the description string.
- ThreadPlanCallFunction had a redundant copy of the thread, and had a
copy of the process that it didn't really need.
llvm-svn: 143419
detecting Objective-C method calls because the
"lldb.call.realName" metadata was no longer
being correctly installed. I fixed this problem.
llvm-svn: 143371
Fixed an issue where if a mach-o symbol table was corrupt and had a string
table offset that is invalid, we could crash. We now properly check the string
table offset and ignore any symbols with invalid strings.
llvm-svn: 143362
Example:
[11:33:09] johnny:/Volumes/data/lldb/svn/trunk/test $ ./dosep.ty -o "-v -n"
dotest.py options: -v -n
Running /Volumes/data/lldb/svn/trunk/test/dotest.py -v -n -p TestPublicAPIHeaders.py /Volumes/data/lldb/svn/trunk/test/api/check_public_api_headers
1: test_sb_api_directory (TestPublicAPIHeaders.SBDirCheckerCase)
Test the SB API directory and make sure there's no unwanted stuff. ... ok
----------------------------------------------------------------------
Ran 1 test in 4.404s
OK
Running /Volumes/data/lldb/svn/trunk/test/dotest.py -v -n -p TestEmulations.py /Volumes/data/lldb/svn/trunk/test/arm_emulation
1: test_arm_emulations (TestEmulations.ARMEmulationTestCase) ... ok
2: test_thumb_emulations (TestEmulations.ARMEmulationTestCase) ... ok
----------------------------------------------------------------------
Ran 2 tests in 1.399s
OK
...
llvm-svn: 143355
ClangExpressionDeclMap to ClangASTSource, and
moved all general type and namespace lookups
into ClangASTSource. Now ClangASTSource is ready
to complete types given nothing more than a target
and an AST context.
llvm-svn: 143292
AST importer on completing namespace mappings from
ClangExpressionDeclMap to ClangASTSource.
ClangASTSource now contains a TargetSP which it
uses to lookup namespaces in all of a target's
modules. I will use the TargetSP in the future to
look up globals.
llvm-svn: 143275
command suffix:
(lldb) expression/x 3+3
Since "expression" is a raw command that has options, we need to make sure the
command gets its options properly terminated with a "--".
Also fixed an issue where if you try to use the GDB command suffix on a
command that doesn't support the "--gdb-format" command, it will report an
appropriate error.
For the fix above, you can query an lldb_private::Options object to see if it
supports a long option by name.
llvm-svn: 143266
allow it to complete types on behalf of any AST context
(including the "scratch" AST context associated with
the target), I scrapped its role as intermediary between
the Clang parser and ClangExpressionDeclMap, and instead
made ClangExpressionDeclMap inherit from ClangASTSource.
After this, I will migrate the functions that complete
types and perform namespace lookups from
ClangExpressionDeclMap to ClangASTSource. Ultimately
ClangExpressionDeclMap's only responsiblity will be to
look up variables and ensure that they are materialized
and dematerialized correctly.
llvm-svn: 143253
things like:
(lldb) x/32xb 0x1000
"x" is an alias to "memory read", so this will actually turn into:
(lldb) memory read --gdb-format=32xb 0x1000
This applies to all commands, so the GDB formats will work with "register read",
"frame variable", "target variable" and others. All commands that can accept
formats, counts and sizes have been modified to support the "--gdb-format"
option.
llvm-svn: 143230
then we spawn child processes (debugserver, etc) and those bad settings get
inherited. We stop this from happening by correctly mucking with the posix
spawn attributes.
llvm-svn: 143176
Fixed an issue where async packets were incurring a delay even though they
were sent correctly. We now properly broadcast the private run state being
resumed correctly. Also fixed logging to reflect what is happening.
llvm-svn: 143154
of reference types. Previously, such variables were
materialized as references to those references, which
caused undesried behavior in Clang and was useless anyway
(the benefit of using references to variables is that it
allows expressions to modify variables in place, but for
references that's not required).
Now we just materialize the references directly, which
fixes a variety of expressions that use references.
llvm-svn: 143137
in the same hashed format as the ".apple_names", but they map objective C
class names to all of the methods and class functions. We need to do this
because in the DWARF the methods for Objective C are never contained in the
class definition, they are scattered about at the translation unit level and
they don't even have attributes that say the are contained within the class
itself.
Added 3 new formats which can be used to display data:
eFormatAddressInfo
eFormatHexFloat
eFormatInstruction
eFormatAddressInfo describes an address such as function+offset and file+line,
or symbol + offset, or constant data (c string, 2, 4, 8, or 16 byte constants).
The format character for this is "A", the long format is "address".
eFormatHexFloat will print out the hex float format that compilers tend to use.
The format character for this is "X", the long format is "hex float".
eFormatInstruction will print out disassembly with bytes and it will use the
current target's architecture. The format character for this is "i" (which
used to be being used for the integer format, but the integer format also has
"d", so we gave the "i" format to disassembly), the long format is
"instruction".
Mate the lldb::FormatterChoiceCriterion enumeration private as it should have
been from the start. It is very specialized and doesn't belong in the public
API.
llvm-svn: 143114
inferior program for the lldb debugger to operate on. The fixed lldb executable
corresponds to r142902.
Plus some minor modifications to the test benchmark to conform to way bench.py
is meant to be invoked.
llvm-svn: 143075
"_cmd", "this", and "self". These variables are handled
differently from all other external variables used by
the expression. Other variables are used indirectly
through the $__lldb_arg operand; only _cmd, this, and
self are passed directly through the ABI.
There are two modifications:
- I added a function to ClangExpressionDeclMap that
retrives the value of one of these variables by name;
and
- I made IRInterpreter fetch these values when needed,
and ensured that the proper level of indirection is
used.
llvm-svn: 143065
be set if linking against an LLVM compiled with
NDEBUG off. If it is set, we do not enable NDEBUG
in any place where we include LLVM headers.
llvm-svn: 143036
properly marked as valid.
Also modified the "memory read" command to be able to intelligently repeat
subsequent memory requests, so now you can do:
(lldb) memory read --format hex --count 32 0x1000
Then hit enter to keep viewing the memory that follows the last valid request.
llvm-svn: 143015
linked against a debug LLVM, runs a variety of
functions -- currently just one -- that verify
that the Decls we create are valid.
ClangASTContext now calls this verifier whenever
it adds a Decl to a DeclContext, and the verifier
checks that the AccessSpecifier is sane.
llvm-svn: 143000
lldb_private::Error objects the rules are:
- short strings that don't start with a capitol letter unless the name is a
class or anything else that is always capitolized
- no trailing newline character
- should be one line if possible
Implemented a first pass at adding "--gdb-format" support to anything that
accepts format with optional size/count.
llvm-svn: 142999
types of the same name. If a local variable with the
given name is found (and we are not searching a
specific namespace) we stop right then and there and
report it.
llvm-svn: 142962
An example (with /Developer/usr/bin/lldb vs. /usr/bin/gdb):
[13:05:04] johnny:/Volumes/data/lldb/svn/trunk/test $ ./dotest.py -v +b -n -p TestCompileRunToBreakpointTurnaround.py
1: test_run_lldb_then_gdb (TestCompileRunToBreakpointTurnaround.CompileRunToBreakpointBench)
Benchmark turnaround time with lldb vs. gdb. ...
lldb turnaround benchmark: Avg: 4.574600 (Laps: 3, Total Elapsed Time: 13.723799)
gdb turnaround benchmark: Avg: 7.966713 (Laps: 3, Total Elapsed Time: 23.900139)
lldb_avg/gdb_avg: 0.574214
ok
----------------------------------------------------------------------
Ran 1 test in 55.462s
OK
llvm-svn: 142949
parser. Now expression like the following work as
expected:
-
(lldb) expr struct { int a; int b; } $blah = { 10, 20 }
<no result>
(lldb) expr $blah
(<anonymous struct at Parse:6:5>) $blah = {
(int) a = 10
(int) b = 20
}
-
Now the IRForTarget subsystem knows how to handle
static initializers of various composite types.
Also removed an unnecessary parameter from
ClangExpressionDeclMap::GetFunctionInfo.
llvm-svn: 142936
for debug information that occasionally gets the
const-ness of member functions wrong. We used to
demangle the name, add "const," and remangle it; now
we handle the mangled name directly, which is more
robust.
llvm-svn: 142933
OptionGroupFormat. Updated OptionGroupFormat to be able to also use the
"--size" and "--count" options. Commands that use a OptionGroupFormat instance
can choose which of the options they want by initializing OptionGroupFormat
accordingly. Clients can either get only the "--format", "--format" + "--size",
or "--format" + "--size" + "--count". This is in preparation for upcoming
chnages where there are alternate ways (GDB format specification) to set a
format.
llvm-svn: 142911
Fixed an issue where bad DWARF from clang would get recycled from DWARF back
into types and cause clang to assert and die, killing the lldb binary, when
it tried to used the type in an expression.
llvm-svn: 142897
function and having it not require both a bool and a quote char to fill in.
We intend to get rid of this functionality when we rewrite the command
interpreter for streams eventually, but not for now.
llvm-svn: 142888
command in the '- Hook id' header. This should improve readbility of the 'display'
command if, for example, we have issued 'display a' and 'display b' which turn into
"target stop-hook add -o 'expr -- a'" and "target stop-hook add -o 'expr -- b'".
Plus some minor change in TestAbbreviations.py to conditionalize the platform-specific
checkings of the "image list" output.
llvm-svn: 142868
A patina of gdb's "display" command, intended mostly for simply monitoring
a variable as you step through source code. Formatters do not work, e.g.
display/x $pc does not work.
llvm-svn: 142710
permits a namespace map to be created and populated
when the namespace is imported, not just when it is
requested via FindExternalVisibleDecls().
llvm-svn: 142690
Example (start the lldb inferior, break at the Driver::MainLoop() function, and
issue 'frame variable'):
$ ./dotest.py -v +b -x '-F Driver::MainLoop()' -n -p TestFrameVariableResponse.py
----------------------------------------------------------------------
Collected 1 test
1: test_startup_delay (TestFrameVariableResponse.FrameVariableResponseBench)
Test response time for the 'frame variable' command. ...
lldb frame variable benchmark: Avg: 1.636897 (Laps: 20, Total Elapsed Time: 32.737944)
ok
----------------------------------------------------------------------
Ran 1 test in 65.105s
OK
llvm-svn: 142678
Johnny Chen