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
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
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
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
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
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
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
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
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
(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
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
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
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
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
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
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
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
There are two tests in this file. One which only runs on Windows
and tests that you can set a breakpoint with mismatched case. And
another that only runs on non-Windows and tests that you cannot set
a breakpoint with mismatched case. This latter test is failing on
non Windows platforms for some reason. It could be that the test
is just written incorrectly, as I think the actual functionality
actually works correctly on non-Windows platforms.
llvm-svn: 261800
Paths on Windows are not case-sensitive. Because of this, if a file
is called main.cpp, you should be able to set a breakpoint on it
by using the name Main.cpp. In an ideal world, you could just
tell people to match the case, but in practice this can be a real
problem as it requires you to know whether the person who compiled
the program ran "clang++ main.cpp" or "clang++ Main.cpp", both of
which would work, regardless of what the file was actually called.
This fixes http://llvm.org/pr22667
Patch by Petr Hons
Differential Revision: http://reviews.llvm.org/D17492
Reviewed by: zturner
llvm-svn: 261771
Mips64 tests were failing on windows because the sscanf implementation differs between clang/gcc/msvc such that on windows %lx specifies a 32bits parameter and %llx is for 64bits. For us this meant that 64bit pointers were being truncated to 32bits on their way into a JIT'd expression.
llvm-svn: 261741
IRExecutionUnit previously replicated a bunch of logic that already
existed elsewhere for the purpose of getting a load address for a
symbol. This approach failed to resolve certain types of symbols.
Instead, we now use functions on SymbolContext to do the address
resolution.
This is a cleanup of IRExecutionUnit::FindInSymbols, and also fixes a
latent bug where we looked at the wrong SymbolContext to determine
whether or not it is external.
<rdar://problem/24770829>
llvm-svn: 261704
Summary:
On arm64, linux<=4.4 and Android<=M there is a bug, which prevents single-stepping from working when
the system comes back from suspend, because of incorrectly initialized CPUs. This did not really
affect Android<M, because it did not use software suspend, but it is a problem for M, which uses
suspend (doze) quite extensively. Fortunately, it seems that the first CPU is not affected by
this bug, so this commit implements a workaround by forcing the inferior to execute on the first
cpu whenever we are doing single stepping.
While inside, I have moved the implementations of Resume() and SingleStep() to the thread class
(instead of process).
Reviewers: tberghammer, ovyalov
Subscribers: aemerson, rengolin, tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D17509
llvm-svn: 261636
Summary:
Signalfd is not used in the code anymore, and given that the same functionality can be achieved
with the new MainLoop class, it's unlikely we will need it in the future. Remove all traces of
it.
Reviewers: tberghammer, ovyalov
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D17510
llvm-svn: 261631
Inline functions in DWARF have AT_abstract_origin set, but we only handled that
if the functions were C++ methods. Inline functions -- C or C++ -- have this
also, and as a result they got one FunctionDecl for each inlined instance. When
going to construct the locals, this meant that the arguments (which did properly
have their abstract origins handled) would get associated with the master
FunctionDecl, and the inlined FunctionDecls would all appear to have no locals.
This manifested as not being able to look up local variables when stopped in an
inline fuunction. We should have had a test for this, but somewhere along the
line the relevant test case lost its .py file (or it never had one).
This patch fixes this problem and restores the .py file.
<rdar://problem/24712434>
llvm-svn: 261598
This patch aims to reduce the code duplication among all of the platforms in GetSoftwareBreakpointTrapOpcode by pushing all common code into the Platform base class.
Differential Revision: http://reviews.llvm.org/D17395
llvm-svn: 261536
This patches does the following:
+ fix return type: ClangExpressionParser::Parse returns unsigned, but was actually returning a signed value, num_errors.
+ use helper clang::TextDiagnosticBuffer::getNumErrors() instead of counting the errors ourself.
+ limit scoping of block-level automatic variables as much as practical.
+ remove reused multipurpose TextDiagnosticBuffer::const_iterator in favour of loop-scoped err, warn, and note variables in the diagnostic printing code.
+ refactor diagnostic printing loops to use a proper loop invariant.
Author: Luke Drummond <luke.drummond@codeplay.com>
Differential Revision: http://reviews.llvm.org/D17273
llvm-svn: 261345
There is a report in the PR from several months ago that it failed
intermittently, but it is passing consistently for me on FreeBSD 10
and 11. We can re-add a decorator if further testing shows it is
still flakey.
llvm.org/pr17214
llvm-svn: 261340
Both Linux and FreeBSD had a comment "This needs to be root-caused."
It looks like the failure has been fixed on both, and the Linux XFAIL
decorator was removed in r233716 (Mar 2015).
llvm-svn: 261333
[git 65dafa83] introduced the GetBuiltinIncludePath function copied from cfe/lib/Driver/CC1Options.cpp
This function is no longer used in lldb's expression parser and I believe it is safe to remove it.
Author: Luke Drummond <luke.drummond@codeplay.com>
Differential Revision: http://reviews.llvm.org/D17266
llvm-svn: 261328
This change is improving the instruction emulation based unwinding to
handle when the frame pointer is adjusted (increment/decrement) after
it has been initialized. The situation can occur in the prologue of
some function where FP is adjusted before it is copied back to SP.
Example code (thumb, generated by gcc 4.8):
< +0>: push {r4, r7, lr}
< +2>: sub sp, #0x14
< +4>: add r7, sp, #0x0
...
<+50>: adds r7, #0x14 ; The CL fixes the handling of this instruction
<+52>: mov sp, r7 ; Previously unwinding from here was broken
<+54>: pop {r4, r7, pc}
Differential revision: http://reviews.llvm.org/D17295
llvm-svn: 261318
working directory by default -- a typical security problem that we
need to be more conservative about.
It adds a new target setting, target.load-cwd-lldbinit which may
be true (always read $cwd/.lldbinit), false (never read $cwd/.lldbinit)
or warn (warn if there is a $cwd/.lldbinit and don't read it). The
default is set to warn. If this is met with unhappiness, we can look
at changing the default to true (to match current behavior) on a
different platform.
This does not affect reading of ~/.lldbinit - that will still be read,
as before. If you run lldb in your home directory, it will not warn
about the presence of a .lldbinit file there.
I had to add two SB API - SBHostOS::GetUserHomeDirectory and
SBFileSpec::AppendPathComponent - for the lldb driver code to be
able to get the home directory path in an OS neutral manner.
The warning text is
There is a .lldbinit file in the current directory which is not being read.
To silence this warning without sourcing in the local .lldbinit,
add the following to the lldbinit file in your home directory:
settings set target.load-cwd-lldbinit false
To allow lldb to source .lldbinit files in the current working directory,
set the value of this variable to true. Only do so if you understand and
accept the security risk.
<rdar://problem/24199163>
llvm-svn: 261280
on attach uses the architecture it has figured out, rather than the Target's
architecture, which may not have been updated to the correct value yet.
<rdar://problem/24632895>
llvm-svn: 261279
The race condition/use after free involved in setting long prompts
appears to be fixed now (although I do not know which commit fixed it).
llvm.org/pr22611
llvm-svn: 261266
Pavel Labath