Zachary introduced the 'default' case explicitly to placate a warning in
the Microsoft compiler but that broke clang with -Werror.
The new code should keep both compilers happy.
llvm-svn: 258212
A few files were accidentally added to the Copy Files build phase for our man
page, and they would appear when 'xcodebuild install' was invoked. This removes
those files – they continue to be built correctly, but they aren't installed
with our man page.
llvm-svn: 258194
Summary:
The issue arises because LLDB is not
able to read the vdso library correctly.
The fix adds memory allocation callbacks
to allocate sufficient memory in case the
requested offsets don't fit in the memory
buffer allocated for the ELF.
Reviewers: lldb-commits, clayborg, deepak2427, ovyalov, labath, tberghammer
Differential Revision: http://reviews.llvm.org/D16107
llvm-svn: 258122
TestHelloWorld seems to be passing now as far as I can tell. TestExitDuringStep is still hanging.
I have marked the relevant tests as flaky, which should handle the timeouts now as well. I'll be
monitoring the buildbots for fallout.
llvm-svn: 258114
The ELF symbol table always contain the size of the symbols so we
don't have to try to guess them based on the address of the next
symbol (it is needed for mach-o).
The change fixes an issue when a symbol is removed after a 0 size
symbol (e.g. because the second one is not public) what previously
caused the symbol lookup algorithm to end up with showing the 0 size
symbol even for the later addresses (what are not part of any symbol).
That symbol lookup error can confuse the user and also confuses the
current stack unwinder.
Re-commit this CL after fixing the issue with gcc-4.9.2 on i386 Linux.
Differential revision: http://reviews.llvm.org/D16186
llvm-svn: 258113
This does not work and causes the class to be silently skipped, which is a bad idea. This makes
sure it cannot happen accidentaly. I've played with the idea of actually making the decorator
work at class level, but it proved too magic to do at this moment.
llvm-svn: 258048
The ELF symbol table always contain the size of the symbols so we
don't have to try to guess them based on the address of the next
symbol (it is needed for mach-o).
The change fixes an issue when a symbol is removed after a 0 size
symbol (e.g. because the second one is not public) what previously
caused the symbol lookup algorithm to end up with showing the 0 size
symbol even for the later addresses (what are not part of any symbol).
That symbol lookup error can confuse the user and also confuses the
current stack unwinder.
Differential revision: http://reviews.llvm.org/D16186
llvm-svn: 258040
Reverts earlier commit r254910, which used function pointers for jitted expressions
to avoid a Mips64 compiler bug. Bug has since been fixed, and compiler longer issues the problem instruction.
Author: Dean De Leo <dean@codeplay.com>
llvm-svn: 258038
TestConcurrentEvents was marked with a XFAIL decorator at class level, which actually does not
work, and causes the class to be silently skipped everywhere. It seems that making it work at
class level is quite a difficult task, so I will just move it to the individual test methods. I
will follow this up with a commit which makes the decorator blow up in case someone tries to
apply it to a class in the future.
llvm-svn: 257901
1) It was forward declaring functions without 'extern "C"'. That used to work
but only because of another bug in how we passes symbol only function names to the
compiler and stopped working recently.
2) These forward declarations were in the body of the User Expression, and they actually
need to go in the prefix file.
<rdar://problem/24177689>
llvm-svn: 257852
If your program refers to modules (as indicated in DWARF) we will now try to
load these modules and give you access to their types in expressions. This used
to be gated by a setting ("settings set target.auto-import-clang-modules true")
but that setting defaulted to false. Now it defaults to true -- but you can
disable it by toggling the setting to false.
llvm-svn: 257812
Both llvm and clang have an ArrayType class, which can cause resolution to fail when llvm headers that are implicitly included name this type.
source/Symbol/ClangASTContext.cpp has 'using namespace llvm;' and 'using namespace clang;'
Author: Luke Drummond <luke.drummond@codeplay.com>
Differential Revision: http://reviews.llvm.org/D16155
llvm-svn: 257759
The Green Dragon LLVM builders are starting to parse xunit output
on LLDB Xcode builders. By default the XML formatter treats
xpass (unexpected successes) as failures. The new flag added
ensures we simply ignore those for purposes of xUnit output.
LLDB is not currently XPASS clean.
llvm-svn: 257717
/work/llvm-3.8/llvm.src/tools/lldb/source/API/SBProcess.cpp:1003:73:
error: format specifies type 'void *' but the argument has type 'lldb_private::Event *' [-Werror,-Wformat-pedantic]
log->Printf ("SBProcess::%s (event.sp=%p) => %d", __FUNCTION__, event.get(), ret_val);
~~ ^~~~~~~~~~~
1 error generated.
llvm-svn: 257692
This is similar to r256407 and fixes the following warning:
In file included from /work/llvm-3.8/llvm.src/tools/lldb/source/Target/ThreadPlanCallFunctionUsingABI.cpp:14:
In file included from /work/llvm-3.8/llvm.src/tools/lldb/include/lldb/Target/ThreadPlanCallFunctionUsingABI.h:23:
/work/llvm-3.8/llvm.src/include/llvm/IR/Type.h:350:16: error: inline function 'llvm::Type::getSequentialElementType' is not defined [-Werror,-Wundefined-inline]
inline Type *getSequentialElementType() const;
^
/work/llvm-3.8/llvm.src/include/llvm/IR/Type.h:353:46: note: used here
Type *getArrayElementType() const { return getSequentialElementType(); }
^
1 error generated.
I'm not sure why it's not showing on any bots.
llvm-svn: 257691
If you have two folders with the same name but different cases,
MSBuild gets confused and generates an error when building
from within Visual Studio.
This patch renames it so that the cases of all folders named
"LLDB tests" match.
Patch by Jonathan Meier
Differential Revision: http://reviews.llvm.org/D16150
llvm-svn: 257684
We already have char** typemaps which were near copy-pastes of
the const char** versions. This way we have only one version that
works for both.
llvm-svn: 257670
There were a number of problems preventing this from working:
1. The SWIG typemaps for converting Python lists to and from C++
arrays were not updated for Python 3. So they were doing things
like PyString_Check instead of using the PythonString from
PythonDataObjects.
2. ProcessLauncherWindows was ignoring the environment completely.
So any test that involved launching an inferior with any kind
of environment variable would have failed.
3. The test itself was using process.GetSTDOUT(), which isn't
implemented on Windows. So this was changed to save the
value of the environment variable in a local variable and
have the debugger look at the value of the variable.
llvm-svn: 257669
Most of the time CONFIGURATION_BUILD_DIR and BUILT_PRODUCTS_DIR are the same,
but they are different in 'xcodebuild install' situations. The file needs to be
put into BUILT_PRODUCTS_DIR or lldb's Python interface doesn't work when lldb is
built using 'xcodebuild install'.
llvm-svn: 257653
We have a check what warns if the offset of a class member is greater
then or equal to the size of the class. The warning is valid in most
case but it is invalid when the last data member is a 0 size array
because in this case the member offset can be equal to the class size
(subject to alignment limitations).
This CL fixis LLDB to not print out a warning in this special case.
llvm-svn: 257603
This is a packet which allows the remote gdb stub to ask for the address
of a symbol in the process. lldb sends the packet (offering to provide
addresses for symbol names) after every solib loaded. I changed lldb so
that once the stub has indicated that it doesn't need any more symbol
addresses, lldb will stop sending the qSymbol:: packet on new solib loads.
This can yield a performance benefit over slower communication links when
there are many solibs involved.
<rdar://problem/23310049>
llvm-svn: 257569
The system can create threads for a system threadpool, so there is
no guarantee that the thread that is stopped is thread 1. So use
a more robust check.
llvm-svn: 257513
Summary:
Allows the remote to enumerate the link map when adding and removing
shared libraries, so that lldb doesn't need to read it manually from
the remote's memory.
This provides very large speedups (on the order of 50%) in total
startup time when using the ds2 remote on android or Tizen devices.
Reviewers: ADodds, tberghammer, tfiala
Subscribers: tberghammer, sas, danalbert, llvm-commits, srhines
Differential Revision: http://reviews.llvm.org/D16004
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 257502
Summary:
The testcase TestNoreturnUnwind.py was failing
because the unwind from the vdso library was not
successful for clang compiler while it was passing
for gcc. It was passing for gcc since the unwind plan
used was the assembly plan and the ebp register was
set by the main function in case of gcc and was not
used by the functions in the call flow to the vdso, whereas
clang did not emit assembly prologue for main and so
the assembly unwind was failing. Normally in case of
failure of assembly unwind, lldb switches to EH CFI frame
based unwinding, but this was not happening for
the first frame. This patch tries to fix this behaviour by
falling to EH CFI frame based unwinding in case of assembly
unwind failure even for the first frame.
The test is still marked as XFAIL since it relys on the fix
of another bug.
Reviewers: lldb-commits, jingham, zturner, tberghammer, jasonmolenda
Subscribers: jasonmolenda
Differential Revision: http://reviews.llvm.org/D15046
llvm-svn: 257465
Summary:
Clang recently added support for an OpenCL pipe type. Adding the new type to relevant switches to
avoid warnings.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16055
llvm-svn: 257460
at each public stop to improve performance a bit. Most of the
information lldb needed was already in the jThreadsInfo response;
complete that information and catch a few cases where we could still
fall back to getting the information via discrete memory reads.
debugserver adds 'associated_with_dispatch_queue' and 'dispatch_queue_t
keys to the jThreadsInfo response for all the threads. lldb needs the
dispatch_queue_t value. And associated_with_dispatch_queue helps to
identify which threads definitively don't have any queue information so
lldb doesn't try to do memory reads to get that information just because
it was absent in the jThreadsInfo response.
Remove the queue information from the questionmark (T) packet. We'll
get the information for all threads via the jThreadsInfo response -
sending the information for the stopping thread (on all the private
stops, plus the less frequent public stop) was unnecessary information
being sent over the wire.
SystemRuntimeMacOSX will try to get information about queues by asking
the Threads for them, instead of reading memory.
ProcessGDBRemote changes to recognize the new keys being sent in the
jThreadsInfo response. Changes to ThreadGDBRemote to track the new
information. Also, when a thread is marked as definitively not
associated with a libdispatch queue, don't fall back to the system
runtime to try memory reads to find the queue name / kind / ID etc.
<rdar://problem/23309359>
llvm-svn: 257453
SUMMARY:
This patch merges emulation of similar instructions into a single function (wherever possible) to remove code duplication.
Reviewers: clayborg
Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential Revision: http://reviews.llvm.org/D16051
llvm-svn: 257442
SUMMARY:
This patch sets up register r25 with the address of function to be called in PrepareTrivialCall().
This is required as per MIPS PIC calling convention.
Reviewers: clayborg
Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential Revision: http://reviews.llvm.org/D16046
llvm-svn: 257441
Summary:
This was used with the old ARM vs. Thumb detection code but is not
required anymore.
Reviewers: tberghammer, clayborg
Subscribers: fjricci, aemerson, lldb-commits, rengolin
Differential Revision: http://reviews.llvm.org/D16099
llvm-svn: 257429
Updated expectedFailureLinux decorator to reflect architecture
Marked some triaged failures as xfails on arm with updated expectedFailureLinux decorator
Differential revision: http://reviews.llvm.org/D15893
llvm-svn: 257405
* lldb::tid_t was being converted incorrectly, so this is updated to use
PythonInteger instead of manual Python Native API calls.
* OSPlugin_RegisterContextData was assuming that the result of
get_register_data was a string, when in fact it is a bytes. So this
method is updated to use PythonBytes to do the work.
llvm-svn: 257398
-gsplit-dwarf is not implemented by clang on Windows. As such,
all the dwo tests are having the -gsplit-dwarf command line option
completely ignored, and the result is you get regular dwarf debug
information, and it's just running the exact same tests twice,
doubling the length of the test suite for no good reason.
llvm-svn: 257363
Summary:
Similar to rL256704 and rL256707, fix a few text files which were
accidentally checked in with DOS line endings, or mixed line endings.
Reviewers: jingham, emaste
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16027
llvm-svn: 257361
Previously we tried to parse the line table even if a compile unit
had no DW_AT_stmt_list atribute. The problem happens when a compiler
generates debug info for a compile unit but doesn't generate any line
info.
llvm-svn: 257335
The test hangs/crashes/fails because it does not use the listener API in a way that LLDB expects.
I don't really know if this is the fault of LLDB of the test...
llvm-svn: 257323
Summary:
On linux we need the process to give us special permissions before we can attach to it.
Previously, the code for this was copied into every file that needed it. This moves the code to a
central place to reduce code duplication.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15992
llvm-svn: 257319
I prefer to use "-p" over using line_number and then setting by line because it's makes it possible
to see what the breakpoint is at the site where you make the breakpoint. So I switched
it back to -p but specified the source file as well, which is an "all within lldb" way of doing
what Pavel's fix did.
llvm-svn: 257235
process in the incoming value be non-null, but Value Objects created off the target
don't necessarily have a process. In that case, having the targets the same is good
enough.
<rdar://problem/24097805>
llvm-svn: 257234
keys before we print the libdispatch queues keys (qname, qkind, qserialnum)
to make it easier to read the packet by hand. No function difference, just
reordering the keys in the output.
llvm-svn: 257229
with the one change that ThreadPlanStepOut::ThreadPlanStepOut
will now only advance the return address breakpoint to
the end of a source line, if we have source line debug information.
It will not advance to the end of a Symbol if we lack source line
information. This, or the recognition of the LEAVE instruction
in r257209, would have fixed the regression that Siva was seeing.
Both were good changes, so I've made both.
Original commit message:
Performance improvement: Change lldb so that it puts a breakpoint
on the first branch instruction after a function return (or the end
of a source line), instead of a breakpoint on the return address,
to skip an extra stop & start of the inferior process.
I changed Process::AdvanceAddressToNextBranchInstruction to not
take an optional InstructionList argument - no callers are providing
a cached InstructionList today, and if this function was going to
do that, the right thing to do would be to fill out / use a
DisassemblerSP which is a disassembler with the InstructionList for
this address range.
http://reviews.llvm.org/D15708
<rdar://problem/23309838>
llvm-svn: 257210
Summary:
When we construct AppleObjCTrampolineHandler, if m_impl_fn_addr is
invalid, we call CanJIT(). If the gdb remote process does not support
allocating and deallocating memory, this call stack will include a call
to the AppleObjCRuntime constructor. The AppleObjCRuntime constructor
will then call the AppleObjCTrampolineHandler constructor, creating a
recursive call loop that eventually overflows the stack and segfaults.
Avoid this call loop by not constructing the AppleObjCTrampolineHandler
within AppleObjCRuntime until we actually need to use it.
Reviewers: clayborg, jingham
Subscribers: sas, lldb-commits
Differential Revision: http://reviews.llvm.org/D15978
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 257204
gcc by default does not accept for loop declarations in C files (one must choose C99 mode first,
which we don't). Place the declaration outside the loop, to make this code more conformant.
llvm-svn: 257166
On locked down systems (such as our buildbot) one needs to do a special dance to allow attaching
to processes. This commit adds this code to the TestBatchMode inferior.
llvm-svn: 257165
New test introduced in r257120 was failing on linux. The reason for that the regex for setting
the breakpoint was being applied to the "default file", which in this case was the asm file
containing the definition of the sleep() syscall (because after attach, we are stopped in the
sleep function). I have changed this use the more customary way of setting the breakpoint and
specifying the source file name explicitly.
llvm-svn: 257160
puts a breakpoint" it is causing a regression in the TestStepNoDebug
test case on ubuntu 14.04 with gcc 4.9.2. Thanks for the email
Siva. I'll recommit when I've figured out the regression.
llvm-svn: 257138
Summary:
If two dwarf sequences begin with entries that have identical addresses,
it is possible for the comparator to order the first entry of the new
sequence between the first and second entries of the existing sequence.
This will result in an attempted insertion of the second sequence inside
of the first sequence, which is invalid.
Ensure that insertions only occur in between existing sequences.
Reviewers: andrew.w.kaylor, clayborg
Subscribers: sas, lldb-commits
Differential Revision: http://reviews.llvm.org/D15979
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 257132
"qserial" to "qserialnum" because "qserial" looks a lot like the
queue type (either 'serial' or 'concurrent') and can be confusing
to read through. debugserver passes these up either in the questionmark
("T") packet, or in the response to the jThreadsInfo packet.
llvm-svn: 257121
Batch mode is supposed to stop execution and return control to the user when an
exceptional stop occurs (crash, signal or instrumentation). But attach always stops
with a SIGSTOP on OSX (maybe on Linux too?) which would short circuit the rest of the
commands given.
This change allows a command result object to indicate that it expected to leave the
process stopped with an exceptional stop reason, and it is okay for batch mode to keep going.
<rdar://problem/22243143>
llvm-svn: 257120
on the first branch instruction after a function return (or the end
of a source line), instead of a breakpoint on the return address,
to skip an extra stop & start of the inferior process.
I changed Process::AdvanceAddressToNextBranchInstruction to not
take an optional InstructionList argument - no callers are providing
a cached InstructionList today, and if this function was going to
do that, the right thing to do would be to fill out / use a
DisassemblerSP which is a disassembler with the InstructionList for
this address range.
http://reviews.llvm.org/D15708
<rdar://problem/23309838>
llvm-svn: 257117
Summary:
Some debug servers don't support it so there's no point in spamming
this.
Reviewers: clayborg
Subscribers: fjricci, lldb-commits
Differential Revision: http://reviews.llvm.org/D15972
llvm-svn: 257116
Summary:
This change is relevant for inferiors compiled with GCC. GCC does not
emit complete debug info for std::basic_string<...>, and consequently, Clang
(the LLDB compiler) does not generate correct mangled names for certain
functions.
This change removes the hard-coded alternate names in
ItaniumABILanguageRuntime.cpp.
Before the hard-coded names were put in ItaniumABILanguageRuntime.cpp, one could
not evaluate std::string methods (ex. std::string::length). After putting in
the hard-coded names, one could evaluate them. However, it did not still
enable one to call methods on, say for example, std::vector<string>.
This change makes that possible.
There is some amount of incompleteness in this change. Consider the
following example:
std::string hello("hello"), world("world");
std::map<std::string, std::string> m;
m[hello] = world;
One can still not evaluate the expression "m[hello]" in LLDB. Will
address this issue in another pass.
Reviewers: jingham, vharron, evgeny777, spyffe, dawn
Subscribers: clayborg, dawn, lldb-commits
Differential Revision: http://reviews.llvm.org/D12809
llvm-svn: 257113
r256927 included a duplicate StreamString header file. This patch simply removes the duplicate.
Author: Luke Drummond <luke.drummond@codeplay.com>
Differential Revision: http://reviews.llvm.org/D15948
llvm-svn: 257061
Updates the file format for storing RS allocations to a file, so that the format now supports struct element types.
The file header will now contain a subheader for every RS element and it's descendants.
Where an element subheader contains element type details and offsets to the subheaders of that elements fields.
Patch also improves robustness when loading incorrect files.
llvm-svn: 257045
The lldbinline inline-test mechanism will create a Makefile
if one does not exist in the test directory. This Makefile
and its *.d files were not getting cleaned up after a test run,
leaving trash in the source tree.
llvm-svn: 256961
Function arguments that were spilled and passed on the stack were incorrectly read.
The value was written back into the output pointer rather then the memory being pointed to.
llvm-svn: 256941
Davide Italiano