| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
InferiorCallPOSIX. It was
set to true, but all plans run by RunThreadPlan need to have this set to false so they will
return control to RunThreadPlan without consulting plans higher on the stack.
Since this seems like a common error, I also modified RunThreadPlan to enforce this behavior.
<rdar://problem/22543166>
llvm-svn: 250084
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Changed from 16 bits to 8 bits for Intel Architecture
-- FXSAVE structure now conforms with the layout of FXSAVE
area specified by IA Architecture Software Developer Manual
- Modified Linux and FreeBSD specific files to support this change
-- MacOSX already uses 8 bits for ftag register
- Modified TestRegisters.py and a.cpp:
-- Change allows 8 bit comparison of ftag values
-- Change resolves Bug 24733:
Removed XFAIL for Clang as the test works and passes for
Clang compiler as well
-- Change provides a Generic/Better way of testing Bug 24457
and Bug 25050 by using 'int3' inline assembly in inferior
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: ovyalov, jingham, clayborg
Subscribers: tfiala, emaste
Differential Revision: http://reviews.llvm.org/D13587
llvm-svn: 250022
|
|
|
|
| |
llvm-svn: 249900
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change, liblldb is 95% of the way towards being able
to work under both Python 2.x and Python 3.x. This should
introduce no functional change for Python 2.x, but for Python
3.x there are some important changes. Primarily, these are:
1) PyString doesn't exist in Python 3. Everything is a PyUnicode.
To account for this, PythonString now stores a PyBytes instead
of a PyString. In Python 2, this is equivalent to a PyUnicode,
and in Python 3, we do a conversion from PyUnicode to PyBytes
and store the PyBytes.
2) PyInt doesn't exist in Python 3. Everything is a PyLong. To
account for this, PythonInteger stores a PyLong instead of a
PyInt. In Python 2.x, this requires doing a conversion to
PyLong when creating a PythonInteger from a PyInt. In 3.x,
there is no PyInt anyway, so we can assume everything is a
PyLong.
3) PyFile_FromFile doesn't exist in Python 3. Instead there is a
PyFile_FromFd. This is not addressed in this patch because it
will require quite a large change to plumb fd's all the way
through the system into the ScriptInterpreter. This is the only
remaining piece of the puzzle to get LLDB supporting Python 3.x.
Being able to run the test suite is not addressed in this patch.
After the extension module can compile and you can enter an embedded
3.x interpreter, the test suite will be addressed in a followup.
llvm-svn: 249886
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
EnablePluginLogging, GetPluginCommandHelp and ExecutePluginCommand aren't
implemented or used anywhere, so remove them from the Hexagon and POSIX
Dynamic Loaders as well as the FreeBSD process.
Reviewers: clayborg, labath, emaste
Subscribers: lldb-commits, emaste
Differential Revision: http://reviews.llvm.org/D13581
llvm-svn: 249840
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg, jingham.
Subscribers: jaydeep, bhushan, sagar, nitesh.jain, brucem,lldb-commits.
Differential Revision: http://reviews.llvm.org/D13548
llvm-svn: 249837
|
|
|
|
| |
llvm-svn: 249827
|
|
|
|
| |
llvm-svn: 249809
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when they introduced android testsuite regressions. Pavel has run the
testsuite against the updated patch and it completes cleanly now.
The original commit message:
Fixing a subtle issue on Mac OS X systems with dSYMs (possibly
introduced by r235737 but I didn't look into it too closely).
A dSYM can have a per-UUID plist in it which tells lldb where
to find an executable binary for the dSYM (DBGSymbolRichExecutable)
- other information can be included in this plist, like how to
remap the source file paths from their build pathnames to their
long-term storage pathnames.
This per-UUID plist is a unusual; it is used probably exclusively
inside apple with our build system. It is not created by default
in normal dSYMs.
The problem was like this:
1. lldb wants to find an executable, given only a UUID
(this happens when lldb is doing cross-host debugging
and doesn't have a copy of the target system's binaries)
2. It eventually calls LocateMacOSXFilesUsingDebugSymbols
which does a spotlight search for the dSYM on the local
system, and failing that, tries the DBGShellCommands
command to find the dSYM.
3. It gets a dSYM. It reads the per-UUID plist in the dSYM.
The dSYM has a DBGSymbolRichExecutable kv pair pointing to
the binary on a network filesystem.
4. Using the binary on the network filesystem, lldb now goes
to find the dSYM.
5. It starts by looking for a dSYM next to the binary it found.
6. lldb is now reading the dSYM over a network filesystem,
ignoring the one it found on its local filesystem earlier.
Everything still *works* but it's much slower.
This would be a tricky one to write up in a testsuite case;
you really need the binary to not exist on the local system.
And LocateMacOSXFilesUsingDebugSymbols will only compile on
Mac OS X - even if I found a way to write up a test case, it
would not run anywhere but on a mac.
One change Greg wanted while I was touching this code was to
have LocateMacOSXFilesUsingDebugSymbols (which could be asked
to find a binary OR find a dSYM) to instead return a ModuleSpec
with the sum total of everything it could find. This
change of passing around a ModuleSpec instead of a FileSpec
was percolated up into ModuleList::GetSharedModule.
The changes to LocateMacOSXFilesUsingDebugSymbols look larger
than they really are - there's a lot of simple whitespace changes
in there.
I ran the testsuites on mac, no new regressions introduced
<rdar://problem/21993813>
llvm-svn: 249755
|
|
|
|
|
|
| |
LanguageRuntime for Go + link against it
llvm-svn: 249681
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In bug 24074, the type information is not shown
correctly. This commit includes the following -
-> Changes for displaying correct type based on
current lexical scope for the command "image
lookup -t"
-> The corresponding testcase.
-> This patch was reverted due to segfaults in
FreeBSD and Mac, I fixed the problems for both now.
Reviewers: emaste, granata.enrico, jingham, clayborg
Differential Revision: http://reviews.llvm.org/D13290
llvm-svn: 249673
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg.
Subscribers: jaydeep, bhushan, sagar, nitesh.jain, lldb-commits.
Differential Revision: http://reviews.llvm.org/D13493
llvm-svn: 249651
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This change fixes pr24916. As associated test has been added.
Reviewers: clayborg
Subscribers: zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D13224
llvm-svn: 249629
|
|
|
|
|
|
|
|
|
|
|
| |
files because SymbolFileDWARFDebugMap didn't implement the following function:
void
ParseDeclsForContext (lldb_private::CompilerDeclContext decl_ctx) override;
Now it does and the test works.
llvm-svn: 249626
|
|
|
|
|
|
|
|
|
| |
Introduce the notion of Language-based formatter prefix/suffix
This is meant for languages that share certain data types but present them in syntatically different ways, such that LLDB can now have language-based awareness of which of the syntax variations it has to present to the user when formatting those values
This is goodness for new languages and interoperability, but is NFC for existing languages. As such, existing tests cover this
llvm-svn: 249587
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13333
llvm-svn: 249570
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The StackUsesFrames and FunctionCallsChangeCFA virtual functions
aren't used anywhere and aren't overridden by anything.
They were introduced when the ABISysV_ppc* code was added and weren't
used at the time. The review for the commit that added them can be
found at http://reviews.llvm.org/D5988
The commit comment notes that backtraces don't yet work:
Backtraces don't work. This is due to PowerPC ABI using a
backchain pointer in memory, instead of a dedicated frame
pointer register for the backchain.
So there is a possibility these were added with the intent of using
them in the future.
Reviewers: clayborg, jingham, jhibbits, emaste
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13506
llvm-svn: 249563
|
|
|
|
| |
llvm-svn: 249531
|
|
|
|
|
|
| |
single character; and also introduce a comparable suffix mechanism
llvm-svn: 249506
|
|
|
|
|
|
|
|
| |
argument, and use it when crafting summaries by running selectors
This is the first in a series of commits that are meant to teach LLDB how to properly handle multi-language formatting of values
llvm-svn: 249503
|
|
|
|
| |
llvm-svn: 249459
|
|
|
|
|
|
| |
GoLanguageRuntime supports finding the runtime type for Go interfaces.
llvm-svn: 249456
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This was deprecated and removed.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13463
llvm-svn: 249452
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bhushan, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13462
llvm-svn: 249405
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SUMMARY:
This patch includes:
1. Emulation of prologue/epilogue and branch instructions for microMIPS.
2. Setting up alternate disassembler (to be used for microMIPS).
So there will be two disassembler instances, one for microMIPS and other for MIPS.
Appropriate disassembler will be used based on the address class of instruction address.
3. Some of the branch instructions does not have fixed sized delay slot, that means delay slot instruction can be of 2-byte or 4-byte.
For this "m_next_inst_size" has been introduced which stores the size of next instruction (i.e size of delay slot instruction in case of branch).
This can be used wherever the size of next instruction is required.
4. A minor change to use mips32 register names instead of mips64 names.
Reviewers: clayborg, tberghammer
Subscribers: mohit.bhakkad, sagar, jaydeep, nitesh.jain, lldb-commits
Differential Revision: http://reviews.llvm.org/D13282
llvm-svn: 249381
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new command 'language renderscript allocation list' for printing the details of all loaded RS allocations.
In order to work out this information lldb JITs the runtime for the data it wants.
This has a penalty of a couple seconds latency, so is only done once for each allocation and the results cached.
If the user later wants to recalculate this information however, they can force lldb to do so with the --refresh flag.
Reviewed by: jingham, clayborg
Subscribers: lldb-commits, ADodds, domipheus, dean, tberghammer, danalbert, srhines
Differential Revision: http://reviews.llvm.org/D13247
llvm-svn: 249380
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- For x86_64-FreeBSD Platform:
-- LLDB now provides correct values of X87 FPU
Special Purpose Registers like fstat, ftag, fctrl etc..
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: emaste, mikesart, clayborg
Subscribers: emaste
Differential Revision: http://reviews.llvm.org/D13434
llvm-svn: 249379
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The concept here is that languages may have different ways of communicating
results. In particular, languages may have different names for their result
variables and in fact may have multiple types of result variables (e.g.,
error results). Materializer was tied to one specific model of result handling.
Instead, now UserExpressions can register their own handlers for the result
variables they inject. This allows language-specific code in Materializer to
be moved into the expression parser plug-in, and it simplifies Materializer.
These delegates are subclasses of PersistentVariableDelegate.
PersistentVariableDelegate can provide the name of the result variable, and is
notified when the result variable is populated. It can also be used to touch
persistent variables if need be, updating language-specific state. The
UserExpression owns the delegate and can decide on its result based on
consulting all of its (potentially multiple) delegates.
The user expression itself now makes the determination of what the final result
of the expression is, rather than relying on the Materializer, and I've added a
virtual function to UserExpression to allow this.
llvm-svn: 249233
|
|
|
|
| |
llvm-svn: 249207
|
|
|
|
| |
llvm-svn: 249206
|
|
|
|
| |
llvm-svn: 249189
|
|
|
|
|
|
|
|
| |
to other types beyond the well-known ones
This is meant to support languages that can do some sort of bridging from<-->to these ObjC types via types that statically vend themselves as Cocoa types, but dynamically have an implementation that does not match any of our well-known types, but where an introspecting formatter can be vended by the bridged language
llvm-svn: 249185
|
|
|
|
|
|
|
| |
Also made it not store nullptrs in its TypeSystemMap, so it will retry to make
the AST context if it errored out last time.
llvm-svn: 249167
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Use .ARM.exidx as a fallback unwind plan for non-call site when the
instruction emulation based unwind failed.
* Work around an old compiler issue where the compiler isn't sort the
entries in .ARM.exidx based on their address.
* Fix unwind info parsing when the virtual file address >= 0x80000000
* Fix bug in unwind info parsing when neither lr nor pc is explicitly
restored.
Differential revision: http://reviews.llvm.org/D13380
llvm-svn: 249119
|
|
|
|
| |
llvm-svn: 249117
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ClangExpressionVariable::CreateVariableInList functions looked cute, but
caused more confusion than they solved. I removed them, and instead made sure
that there are adequate facilities for easily adding newly-constructed
ExpressionVariables to lists.
I also made some of the constructors that are common be generic, so that it's
possible to construct expression variables from generic places (like the ABI and
ValueObject) without having to know the specifics about the class.
llvm-svn: 249095
|
|
|
|
| |
llvm-svn: 249055
|
|
|
|
|
|
|
|
|
|
| |
information by name in a language-specific way.
Currently, it only supports Objective-C - C++ types can be looked up through debug info via 'image lookup -t', whereas ObjC types via this command are looked up by runtime introspection
This behavior is in line with type lookup's behavior in Xcode 7, but I am definitely open to feedback as to what makes the most sense here
llvm-svn: 249047
|
|
|
|
|
|
|
|
| |
Also added some target-level search functions so that persistent variables and
symbols can be searched for without hand-iterating across the map of
TypeSystems.
llvm-svn: 249027
|
|
|
|
| |
llvm-svn: 249021
|
|
|
|
|
|
|
| |
GP registers for o32 applications were always giving zero value because SetType() on the RegisterValue was causing the accessor functions to pickup the value from m_scalar of RegisterValue which is zero.
In this patch byte size and byte order of register value is set at the time of setting the value of the register.
llvm-svn: 249020
|
|
|
|
|
|
|
|
| |
Run the getprop command with AdbClient::Shell instead of
Platform::RunShellCommand because getting the output from getprop
with Platform::RunShellCommand have some (currently unknown) issues.
llvm-svn: 249014
|
|
|
|
|
|
|
|
|
|
| |
Change the way we detect if we have to place a thumb breakpoint instead
of an arm breakpoint in the case when no symbol table or mapping symbols
are available. Detect it based on the LSB of the FileAddress instead of
the LSB of the LoadAddress because the LSB of the LoadAddress is already
masked out.
llvm-svn: 249013
|
|
|
|
|
|
|
|
|
|
| |
The hack is there to work around an incorrect load address reported
by the android linker on API 21 and 22 devices. This CL restricts the
hack to those android API levels.
Differential revision: http://reviews.llvm.org/D13288
llvm-svn: 249012
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D13293
llvm-svn: 248998
|
|
|
|
|
|
|
| |
This reverts commit r248985, as it was breaking all remote
expression-evaluating tests (on android at least).
llvm-svn: 248995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
introduced by r235737 but I didn't look into it too closely).
A dSYM can have a per-UUID plist in it which tells lldb where
to find an executable binary for the dSYM (DBGSymbolRichExecutable)
- other information can be included in this plist, like how to
remap the source file paths from their build pathnames to their
long-term storage pathnames.
This per-UUID plist is a unusual; it is used probably exclusively
inside apple with our build system. It is not created by default
in normal dSYMs.
The problem was like this:
1. lldb wants to find an executable, given only a UUID
(this happens when lldb is doing cross-host debugging
and doesn't have a copy of the target system's binaries)
2. It eventually calls LocateMacOSXFilesUsingDebugSymbols
which does a spotlight search for the dSYM on the local
system, and failing that, tries the DBGShellCommands
command to find the dSYM.
3. It gets a dSYM. It reads the per-UUID plist in the dSYM.
The dSYM has a DBGSymbolRichExecutable kv pair pointing to
the binary on a network filesystem.
4. Using the binary on the network filesystem, lldb now goes
to find the dSYM.
5. It starts by looking for a dSYM next to the binary it found.
6. lldb is now reading the dSYM over a network filesystem,
ignoring the one it found on its local filesystem earlier.
Everything still *works* but it's much slower.
This would be a tricky one to write up in a testsuite case;
you really need the binary to not exist on the local system.
And LocateMacOSXFilesUsingDebugSymbols will only compile on
Mac OS X - even if I found a way to write up a test case, it
would not run anywhere but on a mac.
One change Greg wanted while I was touching this code was to
have LocateMacOSXFilesUsingDebugSymbols (which could be asked
to find a binary OR find a dSYM) to instead return a ModuleSpec
with the sum total of everything it could find. This
change of passing around a ModuleSpec instead of a FileSpec
was percolated up into ModuleList::GetSharedModule.
The changes to LocateMacOSXFilesUsingDebugSymbols look larger
than they really are - there's a lot of simple whitespace changes
in there.
I ran the testsuites on mac, no new regressions introduced
<rdar://problem/21993813>
llvm-svn: 248985
|
|
|
|
|
|
| |
report any (yet).
llvm-svn: 248970
|
|
|
|
|
|
|
|
|
|
| |
the corresponding TypeSystem. This makes sense because what kind of data there
is -- and how it can be looked up -- depends on the language.
Functionality that is common to all type systems is factored out into
PersistentExpressionState.
llvm-svn: 248934
|
|
|
|
| |
llvm-svn: 248909
|