Check that the pc value for frames up the stack is in a
mapped+executable region of memory.
Check that the stack pointer for frames up the stack is
in a mapped+readable region of memory.
If the unwinder ever makes a mistake walking the stack,
these checks will help to keep it from going too far into
the weeds.
These aren't fixing any bugs that I know of, but they
add extra robustness to a complicated task.
llvm-svn: 146478
if this is a mapped/executable region of memory. If it isn't, we've jumped
through a bad pointer and we know how to unwind the stack correctly based
on the ABI.
Previously I had 0x0 special cased but if you jumped to 0x2 on x86_64 one
frame would be skipped because the unwinder would try using the x86_64
ArchDefaultUnwindPlan which relied on the rbp.
Fixes <rdar://problem/10508291>
llvm-svn: 146477
validates the "self," "this," and "_cmd" pointers
that get passed into expressions. It used to check
them aggressively for validity before allowing the
expression to run as an object method; now, this
functionality is gated by a bool and off by default.
Now the default is that when LLDB is stopped in a
method of a class, code entered using "expr" will
always masquerade as an instance method. If for
some reason "self," "this," or "_cmd" is unavailable
it will be reported as NULL. This may cause the
expression to crash if it relies on those pointers,
but for example getting the addresses of ivars will
now work as the user would expect.
llvm-svn: 146465
Modified the Xcode project to not strip liblldb-core.a for BuildAndIntegration builds
and to correctly strip only debug symbols from the command line binaries.
llvm-svn: 146462
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
Jason Molenda