| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
From Adrian McCarthy:
"Running ninja check-lldb now has one crash in a Python process, due to deferencing a null pointer in IRExecutionUnit.cpp: candidate_sc.symbol is null, which leads to a call with a null this pointer."
Reviewers: zturner, spyffe, amccarth
Subscribers: ted, jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D17860
llvm-svn: 263066
|
| |
|
|
|
|
|
|
|
|
|
|
| |
That way you can set offset breakpoints that will move as the function they are
contained in moves (which address breakpoints can't do...)
I don't align the new address to instruction boundaries yet, so you have to get
this right yourself for now.
<rdar://problem/13365575>
llvm-svn: 263049
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The next step is to actually turn CommandAlias into a full-blown CommandObject citizen.
This is tricky given the current architecture of the CommandInterpreter but I think I have found a reasonable path forward.
The current plan is to make class CommandAlias : public CommandObject, and have all the several GetCommand calls not actually traverse through the alias to the underlying command object
The only times that an alias will be traversed are:
a) execution; when time comes to run an alias, I will just grab the underlying command and options, and make the interpreter execute that according to its current algorithm
b) subcommand traversal; if one has an alias to a multiword command, grabbing a subcommand will see through to the subcommand
Other operations, e.g. command listing, command names, command helps, ..., will all use the alias directly. This will, in turn, lead to the removal of the separate alias dictionary, and just mix user commands and aliases in one map
llvm-svn: 262986
|
| |
|
|
|
|
|
|
| |
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17972
llvm-svn: 262970
|
| |
|
|
| |
llvm-svn: 262959
|
| |
|
|
|
|
| |
Store std::unique_ptr<CommandAlias> instead of instances
llvm-svn: 262958
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
self.expect() had two problems:
- If there was a substrs argument, then it overwrote the variable containing
the command to run with the last substr. That meant nonsense command text in
testsuite errors.
- The actual output is not printed, which makes fixing testsuite failures a bit
annoying (you end up having to use the -tv arguments to dotest).
This fixes both of these issues. We could do even better, pretty-printing the
criteria for "correct" output, but this at least makes dealing with errors a bit
better.
llvm-svn: 262950
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The System-V x86_64 ABI requires floating point values to be passed
in 128-but SSE vector registers (xmm0, ...). When printing such a
variable this currently yields an <invalid load address>.
This patch makes LLDB's DWARF expression evaluator accept 128-bit
registers as scalars. It also relaxes the check that the size of the
result of the DWARF expression be equal to the size of the variable to a
greater-than. DWARF defers to the ABI how smaller values are being placed
in a larger register.
Implementation note: I found the code in Value::SetContext() that changes
the m_value_type after the fact to be questionable. I added a sanity check
that the Value's memory buffer has indeed been written to (this is
necessary, because we may have a scalar value in a vector register), but
really I feel like this is the wrong place to be setting it.
Reviewed by Greg Clayton.
http://reviews.llvm.org/D17897
rdar://problem/24944340
llvm-svn: 262947
|
| |
|
|
| |
llvm-svn: 262925
|
| |
|
|
| |
llvm-svn: 262923
|
| |
|
|
| |
llvm-svn: 262920
|
| |
|
|
| |
llvm-svn: 262914
|
| |
|
|
| |
llvm-svn: 262913
|
| |
|
|
|
|
|
|
| |
- move alias help generation to CommandAlias, out of CommandInterpreter
- make alias creation use argument strings instead of OptionArgVectorSP; the former is a more reasonable currency than the latter
- remove m_is_alias from CommandObject, it wasn't actually being used
llvm-svn: 262912
|
| |
|
|
|
|
|
| |
Eventually, there will be more things that CommandAlias contains, and I don't want accessors for each of them on the CommandIntepreter
Eventually, we also won't pass around copies of CommandAlias, but that's for a later patch
llvm-svn: 262909
|
| |
|
|
|
|
| |
template function in lldb_private
llvm-svn: 262905
|
| |
|
|
| |
llvm-svn: 262904
|
| |
|
|
|
|
|
|
| |
any instance data on the CommandInterpreter anyway
This small step removes one piece of alias machinery from the CommandInterpreter into the CommandAlias
llvm-svn: 262901
|
| |
|
|
|
|
|
|
|
|
|
| |
the alias -> underlying command binding and another map holds the alias -> options, to a model where one single map holds the alias -> (all useful data) combination
Right now, obviously, this is just the pair of (CommandObjectSP,OptionArgVectorSP), so NFC
This is step one of a larger - and tricky - refactoring which will turn command aliases into interesting objects instead of passive storage that the command interpreter does smart things to
This refactoring, in turn, will allow us to do interesting things with aliases, such as intelligent and customizable help
llvm-svn: 262900
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
to each other. This should remove some infrequent teardown crashes when the
listener is not the debugger's listener.
Processes now need to take a ListenerSP, not a Listener&.
This required changing over the Process plugin class constructors to take a ListenerSP, instead
of a Listener&. Other than that there should be no functional change.
<rdar://problem/24580184> CrashTracer: [USER] Xcode at …ework: lldb_private::Listener::BroadcasterWillDestruct + 39
llvm-svn: 262863
|
| |
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain
Reviewers: clayborg, jaydeep.
Subscribers: bhushan, mohit.bhakkad, sagar, lldb-commits.
Differential Revision: http://reviews.llvm.org/D17597
llvm-svn: 262819
|
| |
|
|
|
|
|
| |
group to fix a build time issue.
<rdar://problem/24287153>
llvm-svn: 262816
|
| |
|
|
| |
llvm-svn: 262739
|
| |
|
|
| |
llvm-svn: 262715
|
| |
|
|
|
|
|
|
| |
The problem with the original patch (and my first attempt to fix) was that the value debug
monitor flags could persist from one test to another. Resetting the value in the setUp() function
fixes the problem.
llvm-svn: 262713
|
| |
|
|
| |
llvm-svn: 262712
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLDB can remap a source file to a new directory based on the
"target.sorce-map" to handle the usecase when the source code moved
between the compliation and the debugging. Previously the remapping
was only used to display the content of the file. This CL fixes the
scenario when a breakpoint is set based on the new an absolute path
with adding an inverse remapping step before looking up the breakpoint
location.
Differential revision: http://reviews.llvm.org/D17848
llvm-svn: 262711
|
| |
|
|
|
|
|
| |
Even after the last fixup, there still seems to be one failure left. Revert until I figure out
what is going on.
llvm-svn: 262622
|
| |
|
|
| |
llvm-svn: 262602
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
this enables download of remote log files for llgs and debugserver tests (previously we were just
passing the host file name which obviously did not work). Note this also changes the debugserver
logging to work only when logging has been requested on the command line, whereas previously it
would log unconditionally. I can change it back if anyone is relying on this, but I thought I'd
make this consistent.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17798
llvm-svn: 262597
|
| |
|
|
|
|
| |
other minor fixes.
llvm-svn: 262570
|
| |
|
|
|
|
|
|
|
|
| |
These files won't build for ios etc arm builds of lldb and aren't
used for macosx native lldb's.
http://reviews.llvm.org/D17750
<rdar://problem/24287153>
llvm-svn: 262566
|
| |
|
|
|
|
| |
up to date after 4262528.
llvm-svn: 262543
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This makes cloning (and therefore the whole build) faster.
The checkout step goes from ~4m to ~30s on my host.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17425
llvm-svn: 262513
|
| |
|
|
|
|
|
|
|
| |
Previously we were using thumbv7 and armv8.1a what ended up showing a
few undefined instruction when disassembling code. This CL update the
architectures used to armv8.2a and thumbv8.2a (newest available) so we
display all instruction in the disassambly.
llvm-svn: 262482
|
| |
|
|
|
|
| |
other minor fixes.
llvm-svn: 262450
|
| |
|
|
|
|
| |
other minor fixes.
llvm-svn: 262441
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Recent changes to the expression parser broke function name resolution when using the IR interpreter instead of JIT. This patch changes the IRMemoryMap ivar in InterpreterStackFrame to an IRExecutionUnitSP (which is a subclass), allowing InterpreterStackFrame::ResolveConstantValue() to call FindSymbol() on the name of the Value when it's a FunctionVal. It also changes IRExecutionUnit::FindInSymbols() to call GetFileAddress() on the symball if ResolveCallableAddress() fails and there is no valid Process.
Reviewers: spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17745
llvm-svn: 262407
|
| |
|
|
|
|
|
|
|
| |
If we have a TargetLoadAddress on the top of the DWARF stack then a
DW_OP_plus or a DW_OP_plus_ucons sholudn't dereference (resolve) it
and then add the value to the dereferenced value but it should offset
the load address by the specified constant.
llvm-svn: 262339
|
| |
|
|
|
|
| |
we're sometimes getting an exception here, and I want to see why...
llvm-svn: 262333
|
| |
|
|
| |
llvm-svn: 262322
|
| |
|
|
|
|
|
| |
that happened in other parts of this file so it builds cleanly
for arm again.
llvm-svn: 262300
|
| |
|
|
|
|
| |
Will be good idea to introduce macro/constexpr for NULL thread_result_t.
llvm-svn: 262287
|
| |
|
|
|
|
| |
source/Target/Process.cpp; other minor fixes.
llvm-svn: 262281
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
points the user to the apropos and type lookup commands
This is useful in cases such as, e.g.
(lldb) help NSString
(the user meant type lookup)
or
(lldb) help kill
(the user is looking for process kill)
Fixes rdar://24868537
llvm-svn: 262271
|
| |
|
|
|
|
| |
up empty
llvm-svn: 262260
|
| |
|
|
|
|
|
|
| |
This makes it so that help language provides help on the language command and help source-language provides the list of source languages one can pass as an option
Fixes rdar://24869942
llvm-svn: 262259
|
| |
|
|
|
|
|
|
| |
This is a mechanical refactor. There should be no functional changes in this commit.
Instead of encapsulating just the Windows-specific data, ProcessWinMiniDump now uses a private implementation class. This reduces indirections (in the source). It makes it easier to add private helper methods without touching the header and allows them to have platform-specific types as parameters. The only trick was that the pimpl class needed a back pointer in order to call a couple methods.
llvm-svn: 262256
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The inlining semantics for C and C++ are different, which affects the test's expectation of the number of times the function should appear in the binary. In the case of this test, C semantics means there should be three instances of inner_inline, while C++ semantics means there should be only two.
On Windows, clang uses C++ inline semantics even for C code, and there doesn't seem to be a combination of compiler flags to avoid this.
So, for consistency, I've recast the test to use C++ everywhere. Since the test resided under lang/c, it seemed appropriate to move it to lang/cpp.
This does not address the other XFAIL for this test on Linux/gcc. See https://llvm.org/bugs/show_bug.cgi?id=26710
Differential Revision: http://reviews.llvm.org/D17650
llvm-svn: 262255
|