| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
containers
Fixes rdar://23715118
llvm-svn: 262254
|
|
|
|
|
|
| |
other minor fixes.
llvm-svn: 262246
|
|
|
|
|
|
|
|
|
|
|
|
| |
SysV ARM (hard/soft) ABI."
This partially reverts commit r262218.
The commit added additional checks to a test case. The test case is too big so it's not feasible
to XFAIL it completely. Suggest to implement the checks as a separate test case, which can then
be XFAILed more surgically.
llvm-svn: 262223
|
|
|
|
|
|
|
|
|
|
| |
(hard/soft) ABI.
For details see:
Differential revision: http://reviews.llvm.org/D17708
llvm-svn: 262218
|
|
|
|
| |
llvm-svn: 262214
|
|
|
|
|
|
|
|
|
| |
This reverts commit r262041, which caused asserts starting yesterday on the OS X testbot.
See details in:
https://llvm.org/bugs/show_bug.cgi?id=26758
llvm-svn: 262156
|
|
|
|
| |
llvm-svn: 262090
|
|
|
|
|
|
| |
source/Plugins/ABI; other minor fixes.
llvm-svn: 262082
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: aidan.dodds, mamai
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17658
llvm-svn: 262081
|
|
|
|
|
|
| |
added.
llvm-svn: 262055
|
|
|
|
|
|
|
|
| |
methods are thread safe.
<rdar://problem/22595283>
llvm-svn: 262053
|
|
|
|
|
|
|
| |
but kept looking through .o files even after it had found as many
matches as were requested.
llvm-svn: 262051
|
|
|
|
|
|
|
|
| |
Committed on behalf of: ldrumm <luke.drummond@codeplay.com>
Differential revision: http://reviews.llvm.org/D16412
llvm-svn: 262043
|
|
|
|
|
|
|
|
|
|
| |
The evaluation of expressions containing register values was broken for targets for which endianness differs from host.
Committed on behalf of: mamai <marianne.mailhot.sarrasin@gmail.com>
Differential revision: http://reviews.llvm.org/D17167
llvm-svn: 262041
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
popped from functions that are run due to something that is NOT input from the user. All other IOHandler objects result from input from the user. An issue rose up where if a command caused the process to resume and stop and process state changed, where state changed Event objects were broadcast, it would cause the IOHandlerProcessSTDIO to have its IOHandlerProcessSTDIO::Cancel() function called. This used to always write a byte to the control pipe (IOHandlerProcessSTDIO::m_pipe) even if the IOHandlerProcessSTDIO::Run() was never called. What would happen is:
(lldb) command_that_steps_process_thousands_of_times
As the "command_that_steps_process_thousands_of_times" could be a python command that resumed the process thousands of times and in doing so the IOHandlerProcessSTDIO would get pushed when the process resumed, and popped when it stoppped, causing the call to IOHandlerProcessSTDIO::Cancel(). Since the IOHandler thread is currently in IOHandlerEditline::Run() for the command interpreter handling the "command_that_steps_process_thousands_of_times" command, IOHandlerProcessSTDIO::Run() would never get called, even though the IOHandlerProcessSTDIO is on the top of the stack. This caused the command pipe to keep getting 1 bytes written each time the IOHandlerProcessSTDIO::Cancel() was called and eventually we will deadlock since the write buffer is full.
The fix here is to make sure we are in IOHandlerProcessSTDIO::Run() before we write anything to the command pipe, and just call SetIsDone(true) if we are not.
<rdar://problem/22361364>
llvm-svn: 262040
|
|
|
|
| |
llvm-svn: 262028
|
|
|
|
| |
llvm-svn: 262023
|
|
|
|
|
|
|
|
|
|
| |
platform::GetSoftwareBreakpointTrapOpcode().
The software breakpoint definitions for mips32 should have been included in my
recent patch that moved the software breakpoint definitions into the base platform
class.
llvm-svn: 262021
|
|
|
|
| |
llvm-svn: 262016
|
|
|
|
|
|
|
|
|
| |
The purpose of these plugins is to make LLDB capable of debugging java
code JIT-ed by the android runtime.
Differential revision: http://reviews.llvm.org/D17616
llvm-svn: 262015
|
|
|
|
|
|
|
|
|
| |
Additionally fix the type of some dwarf expression where we had a
confusion between scalar and load address types after a dereference.
Differential revision: http://reviews.llvm.org/D17604
llvm-svn: 262014
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain.
Summary: The debug version of libc.so is require for backtracing which may not be available on all platforms.
Reviewers: ovyalov, clayborg
Subscribers: zturner, lldb-commits, mohit.bhakkad, sagar, bhushan, jaydeep
Differential: http://reviews.llvm.org/D17131
llvm-svn: 262011
|
|
|
|
| |
llvm-svn: 261974
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This fixes the 'p' command which should be aliased to 'expresion --'.
Reviewers: jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17634
llvm-svn: 261969
|
|
|
|
|
|
|
|
|
| |
"sif <target function>" - i.e. step-into-function
to allow you to step through a complex calling sequence into a particular function that may span multiple lines. Also some
test cases for this and the --step-target feature.
llvm-svn: 261953
|
|
|
|
|
|
| |
source/Plugins/ABI; other minor fixes.
llvm-svn: 261952
|
|
|
|
|
|
| |
the right thing and break.
llvm-svn: 261950
|
|
|
|
|
|
| |
source/Commands/CommandObjectThread.cpp; other minor fixes.
llvm-svn: 261936
|
|
|
|
|
|
| |
source/Commands/CommandObjectTarget.cpp; other minor fixes.
llvm-svn: 261920
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
the python2 branch seems erroneous as it expected the object to be both a "String" and "Bytes".
Fix the expectation.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17545
llvm-svn: 261901
|
|
|
|
|
|
|
|
|
|
| |
ClangExpressionParser::FindFunctionInModule
Committed on behalf of: Luke Drummond
Differential Revision: http://reviews.llvm.org/D17274
llvm-svn: 261861
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most address represented in lldb as section plus offset and handling of
absolute addresses is problematic in several location because of lack
of necessary information (e.g. Target) or because of performance issues.
This CL change the way ObjectFileELF handle the absolute symbols with
creating a pseudo section for each symbol. With this change all existing
code designed to work with addresses in the form of section plus offset
will work with absolute symbols as well.
Differential revision: http://reviews.llvm.org/D17450
llvm-svn: 261859
|
|
|
|
|
|
|
|
|
|
|
| |
DWARF stores this information in the DW_AT_start_scope attribute. This
CL add support for this attribute and also changes the functions
displaying frame variables to only display the variables currently in
scope.
Differential revision: http://reviews.llvm.org/D17449
llvm-svn: 261858
|
|
|
|
|
|
| |
source/Commands/CommandObjectType.cpp; other minor fixes.
llvm-svn: 261817
|
|
|
|
|
|
|
|
| |
locally on the current machine.
<rdar://problem/24807382>
llvm-svn: 261812
|
|
|
|
|
|
|
|
| |
Test expects the breakpoint to resolve to three locations, but clang on windows yields only 2.
llvm.org/pr26710
llvm-svn: 261810
|
|
|
|
|
|
|
|
|
|
|
|
| |
32-bit processes on 64-bit Windows run in a layer called WoW64 (Windows-on-Windows64). If you capture a mini dump of such a process from a 32-bit debugger, you end up with a register context for the 64-bit WoW64 process rather than the 32-bit one you probably care about.
This detects WoW64 by looking to see if there's a module named wow64.dll loaded. For such processes, it then looks in the 64-bit Thread Environment Block (TEB) to locate a copy of the 32-bit CONTEXT record that the plugin needs for the register context.
Added some rudimentary tests. I'd like to improve these later once we figure out how to get the exception information from these mini dumps.
Differential Revision: http://reviews.llvm.org/D17465
llvm-svn: 261808
|