| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch marks some known failures and puts on expectedFailureLinux decorator to have testsuite xfail them.
Affected tests are:
test/functionalities/watchpoint/step_over_watchpoint.py
test/functionalities/watchpoint/watchpoint_set_command/TestWatchLocationWithWatchSet.py
test/tools/lldb-server/TestGdbRemoteSingleStep.py
test/tools/lldb-server/TestGdbRemote_vCont.py
llvm-svn: 258315
|
|
|
|
|
|
|
|
| |
std::array should have "the same semantics as a struct holding a C-style array T[N] as its only
non-static data member", so the initialization should have one more level of braces. Hopefully,
no compiler will object to that.
llvm-svn: 258306
|
|
|
|
|
|
| |
Test has been passing at least the last 200 buildbot runs.
llvm-svn: 258305
|
|
|
|
|
|
| |
The test has been passing reliably the last 100 runs of the build bot.
llvm-svn: 258304
|
|
|
|
|
|
|
| |
Patch adds command 'language renderscript kernel coordinate' for printing the kernel index in (x,y,z) format.
This is done by walking the call stack and looking for a function with suffix '.expand', as well as the frame variables containing the coordinate data.
llvm-svn: 258303
|
|
|
|
|
|
|
|
|
|
| |
register set indicated by ARM_THREAD_STATE32 (value 9) instead of
the old ARM_THREAD_STATE (value 1); this patch changes lldb to
accept either register set flavor code.
<rdar://problem/24246257>
llvm-svn: 258289
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 258199
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
its clients can easily dump it out for informational messages.
http://reviews.llvm.org/D16244
Submitting on behalf of vishwesh@google.com.
llvm-svn: 258150
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 258080
|
|
|
|
|
|
| |
it isn't used in the code anymore, and we're trying to cut down on the decorators.
llvm-svn: 258049
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
It causes issues for i386 when compiling with gcc-4.9.2
This reverts commit e248214a3eab8e244095f97d1996c991cb988cc4.
llvm-svn: 258043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 257959
|
|
|
|
|
|
|
| |
We can't assume that the main thread of an inferior has index 0,
even in a single-threaded app.
llvm-svn: 257946
|
|
|
|
| |
llvm-svn: 257945
|
|
|
|
| |
llvm-svn: 257931
|
|
|
|
| |
llvm-svn: 257926
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 257829
|
|
|
|
| |
llvm-svn: 257818
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
I was calling the base class tearDown() function the wrong way
which for some reason is ok on Python 3 but not on Python 2.
llvm-svn: 257788
|
|
|
|
|
|
| |
This can happen with -gmodules tables when an anonymous struct is referred to.
llvm-svn: 257786
|
|
|
|
|
|
| |
This patch adds a hook to track kernel invocations and to track all script and allocation objects used.
llvm-svn: 257772
|
|
|
|
| |
llvm-svn: 257761
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 257755
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 257690
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 257671
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 257656
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
output if an immediate output file was set in the result object via a Python file object
Fixes rdar://24130303
llvm-svn: 257644
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain.
Summary: This patch adds check for the correctness of disassembling instruction for MIPS target.
Reviewers: emaste, clayborg, ovyalov
Subscribers: lldb-commits, mohit.bhakkad, sagar, bhushan, jaydeep
Differential: http://reviews.llvm.org/D15915
llvm-svn: 257587
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: zturner
Subscribers: zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D16125
llvm-svn: 257531
|