The ARM instruction emulator had 2 bugs related to the handling of the
IT instruction causing an error in single stepping:
* We haven't initialized the IT mask from the CPSR so if the last
instruction of the IT block is a branch and the condition is false
then the emulator evaluated the branch what resulted in an incorrect
pc for the next instruction.
* The ITSTATE was advanced before the execution of each instruction. As
a result the emulator was using the condition of following instruction
in every case. The ITSTATE should be edvanced after the execution of
an instruction except after an IT instruction.
Differential revision: http://reviews.llvm.org/D16772
llvm-svn: 259509
Summary:
r259344 introduced a bug, where we fail to perform a single step, when the instruction we are
stepping onto contains a breakpoint which is not valid for this thread. This fixes the problem
and add a test case.
Reviewers: tberghammer, emaste
Subscribers: abhishek.aggarwal, lldb-commits, emaste
Differential Revision: http://reviews.llvm.org/D16767
llvm-svn: 259488
r259433 introduced a regression, where if a compiler is specified without a path (e.g., CC=clang,
relying on the fact that clang is in $PATH), then the test suite would fail (at the compiler
version detection step) because realpath would interpret this as a path relative to cwd). The fix
is to perform the $PATH expansion (via `which`) before the realpath step.
llvm-svn: 259484
Summary:
Checks using the result of getCompiler() will fail to identify the compiler
correctly if CC is a symlink path (ie /usr/bin/cc).
Reviewers: zturner, emaste
Subscribers: llvm-commits, sas
Differential Revision: http://reviews.llvm.org/D16488
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 259433
This patch attempts to solve the Python 2 / Python 3 incompatibilities by
introducing a new `encoded_file` abstraction that we use instead of
`io.open()`. The problem with the builtin implementation of `io.open` is
that `read` and `write` accept and return `unicode` objects, which are not
always convenient to work with in Python 2. We solve this by making
`encoded_file.open()` return the same object returned by `io.open()` but
with hooked `read()` and `write()` methods. These hooked methods will
accept binary or text data, and conditionally convert what it gets to a
`unicode` object using the correct encoding. When calling `read()` it
also does any conversion necessary to convert the output back into the
native `string` type of the running python version.
Differential Revision: http://reviews.llvm.org/D16736
llvm-svn: 259379
Summary:
I've run into an issue when running unit tests, where the underlying problem turned out to be
that we were creating Timer objects (through several layers of indirection) without calling
Timer::Initialize. Since Timer's thread-local storage was not properly initialized, we were
overwriting gtest's own thread-local storage, causing test failures.
Instead of requiring that every test calls Timer::Initialize(), I remove the function altogether:
The thread-local storage can be initialized on-demand, and the g_file variable initialized to
stdout and never changed, so I have simply removed it.
Reviewers: clayborg, zturner, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16722
llvm-svn: 259356
Summary:
- The patch solves Bug 23478 and Bug 19311. Resolving
Bug 23478 also resolves Bug 23039.
Correct ThreadStopInfo is set for Linux and FreeBSD
platforms.
- Summary:
When a trace event is reported, we need to check
whether the trace event lands at a breakpoint site.
If it lands at a breakpoint site then set the thread's
StopInfo with the reason 'breakpoint'. Else, set the reason
to be 'Trace'.
Change-Id: I0af9765e782fd74bc0cead41548486009f8abb87
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: jingham, emaste, lldb-commits, clayborg, ovyalov
Subscribers: emaste
Differential Revision: http://reviews.llvm.org/D16720
llvm-svn: 259344
Summary:
The BUILD_SHARED_LIBS branch of lldb-server link flags was hopelessly broken, at least since we
started restricting the symbols exported by liblldb. lldb-server depends on symbols from the
lldb_private namespace, so it cannot link to the public interface of liblldb. Instead I make it
link to the individual libraries constituting liblldb, just like it does in the
!BUILD_SHARED_LIBS case.
This does not make the BUILD_SHARED_LIBS build of lldb fully functional yet, due to the way
liblldb dependencies are managed, but it's a step in that direction.
Reviewers: zturner, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16678
llvm-svn: 259188
Patch deletes the 'language renderscript module probe' command.
This command was present in the initial commit to help debug the plugin.
However we haven't used it recently and it's functionality is unclear, so can be removed entirely.
Also add back 'kernel coordinate' command, removed by accident in clang format patch r259056.
llvm-svn: 259181
Summary:
m_function_name will contain a dummy name for the auto-generated function from
the python script on Linux. Check for script name first.
Reviewers: granata.enrico
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16703
llvm-svn: 259153
The Visual Studio 2015 build was failing with the following error:
error C2440: 'initializing': cannot convert from 'const char [12]' to 'char *'
This should fix the problem by initializing a non const char array, instead of taking a pointer to const static data.
llvm-svn: 259042
This change restores the Xcode build to working after Makefile support
was stripped from LLVM and clang recently.
With this change, the Xcode build now requires cmake (2.8.12.2+).
The cmake must either be on the path that Xcode sees, or it must
exist in one of the following locations:
* /usr/local/bin/cmake
* /opt/local/bin/cmake
* $HOME/bin/cmake
If the ninja build tool is present on the path, it will be used.
If not, ninja will be cloned (via git), bootstrap-built, and
used for the llvm/clang build.
LLDB now requires a minimum deployment target of OS X 10.9. Prior
to this, it was 10.8. The llvm/clang cmake build will not run
with Xcode 7.2 or Xcode 7.3 beta's compiler with the minimum
deployment target set to anything lower than 10.9. This is
related to #include <atomic>.
When llvm or clang source code does not exist in the lldb tree,
it will be cloned via git using http://llvm.org/git/{project}.git.
Previously it used SVN. If this causes any heartache, we can
make this smarter, autodetect an embedded svn and use svn instead.
(And/or use SVN if a git command is not available).
This change also fixes an lldb-mi linkage failure (needed
libncurses) as exposed by one of the LLVM libs.
llvm-svn: 259027
Instead of opening the file in unicode mode, we need only encode
data which potentially has non-ASCII characters as UTF8 before
writing. This should work across both Python versions, and is
also far simpler than anything else discussed.
llvm-svn: 258969
* basestring is not a thing anymore. Must use `six.string_types`.
* Must use from __future__ import print_function in every new test
file.
llvm-svn: 258967
Previously the logic of skipIf and expectedFailure were 99%
the same, but they took different sets of arguments since they
were maintained separately, and had slightly differences in
their behavior. This makes everything consistent, there is now
only one real implementation, and the previous ones are changed
to use the single master implementation.
llvm-svn: 258966
Since pexpect doesn't exist on Windows, tests which are xfail'ed
are not being run at all because they are failing when the file
is imported due to the `import pexpect`. This puts the import
behind a conditional and makes an empty base class in the case
where pexpect is not present.
llvm-svn: 258965
Linking with LLVM shared libraries currently produces linker errors. This works around the issue
(pr24953) by disabling linking with llvm so for lldb libraries.
Patch by Evangelos Foutras.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16293
llvm-svn: 258921
SUMMARY:
Get the load address for the address given by symbol and function.
Earlier, this was done for function only, this patch does it for symbol too.
This patch also adds TestAvoidBreakpointInDelaySlot.py to test this change.
Reviewers: clayborg
Subscribers: labath, zturner, mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential Revision: http://reviews.llvm.org/D16049
llvm-svn: 258919
Seems that the patch was rebased on top of another change which obsoleted the
change but wasnt caught.
Thanks to nbjoerg for pointing this out!
llvm-svn: 258821
Patch replaces the 'renderscript allocation list' command flag --refresh, with a new option --id <ID>.
This new option only prints the details of a single allocation with a given id, rather than printing all the allocations.
Functionality from the removed '--refresh' flag will be moved into its own command in a subsequent commit.
llvm-svn: 258800
This is another example of a test that was looking for the thread
at index 0 instead of requesting the thread that was stopped at
the created breakpoint. This assumption isn't true on Windows 10.
llvm-svn: 258764
lldbinline tests previously did not run correctly unless there was already a
Makefile for them. This was because the syntax of the emitted Makefile made the
default make rule be the "cleanup" rule, which is pretty unhelpful. Now the
default rule is the one included from Makefile.rules, which is much better.
llvm-svn: 258763
Previously we were writing in the default encoding, which depends
on the operating system and is not guaranteed to be unicode aware.
On Python 3, this would lead to a situation where writing unicode
text to the log file generates an exception. The fix here is to
write session logs using the proper encoding, which incidentally
fixes another test, so xfail is removed from that.
llvm-svn: 258759
This fixes the regression of several tests on Windows after rL258621.
The root problem is that ObjectFilePECOFF was not setting type information for the symbols, and the new CL rejects symbols without type information, breaking functionality like thread step-over.
The fix sets the type information for functions (and creates a TODO for other types).
Along the way, I fixed some typos and formatting that made the code I was debugging harder to understand.
In the long run, we should consider replacing most of ObjectFilePECOFF with the COFF parsing code from LLVM.
Differential Revision: http://reviews.llvm.org/D16563
llvm-svn: 258758
In Python 3, whitespace inconsistences are errors. This synthetic
provider had mixed tabs and spaces, as well as inconsistent
indentation widths. This led to the file not being imported,
and naturally the test failing. No functional change here, just
whitespace.
llvm-svn: 258751
SBProcess::ReadMemory and other related functions such as
WriteMemory are returning Python string() objects. This means
that in Python 3 that are returning Unicode objects. In reality
they should be returning bytes objects which is the same as a string
in Python 2, but different in Python 3. This patch updates the
generated SWIG code to return Python bytes objects for all
memory related functions.
One quirk of this patch is that the C++ signature of ReadCStringFromMemory
has it writing c-string data into a void*. This confuses our swig
typemaps which expect that a void* means byte data. So I hacked up
a custom typemap which maps this specific function to treat the
void* as string data instead of byte data.
llvm-svn: 258743
This needs to be able to handle bytes, strings, and bytearray objects.
In Python 2 this was easy because bytes and strings are the same thing,
but in Python 3 the 2 cases need to be handled separately. So as not
to mix raw Python C API code with PythonDataObjects code, I've also
introduced a PythonByteArray class to PythonDataObjects to make the
paradigm used here consistent.
llvm-svn: 258741
Python 3.5 is picky about writing strings to binary files, so we now open the
file in text mode, and we explicitly set the newline mode to avoid re-writing
it with CR+LF on Windows (which causes git to think the file had changed).
llvm-svn: 258704
Patch by Nitesh Jain.
Summary: The thread_start function in libc doesn't contain any epilogue and prologue instructions. Hence unwinding fail when we are stopped in thread_start.
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits, mohit.bhakkad, sagar, bhushan, jaydeep
Differential: reviews.llvm.org/D16136
llvm-svn: 258685
Patch by Nitesh Jain.
Summary: When incorrect type used for 'char' then (at least) one of the expression evaluates to incorrect value. Please refer to bug llvm.org/pr23069
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits, mohit.bhakkad, sagar, bhushan, jaydeep
Differential: reviews.llvm.org/D16132
llvm-svn: 258684
This is hitting an assert in clang when evaluating the
module load. I am seeing it locally on Xcode 7.3 public Beta 1
and on the llvm.org Green Dragon buildbot supposedly running
Xcode 7.0.
Tracked by:
https://llvm.org/bugs/show_bug.cgi?id=26267
llvm-svn: 258602
Since Unicode support is different in Py2 and Py3, Py3 was throwing
exceptions about being unable to decode the file with the default
encoding.
llvm-svn: 258588
The Windows 10 loader spawns threads at startup, so
tests which count threads or assume that a given user
thread will be at a specific index are incorrect in
this case. The fix here is to use the standard mechanisms
for getting the stopped thread (which is all we are
really interested in anyway) and correlating them with
the breakpoints that were set, and doing checks against
those things.
This fixes about 6 tests on Windows 10.
llvm-svn: 258586
The python test run target started failing recently.
I tracked it down to what looks like the passing of
environment variables into the python script.
This locally fixes the vast majority of errors that
were ultimately inferior test build command failures.
Not sure what caused that to start happening.
llvm-svn: 258585
Primarily a trial test for me to try out the
git clang-format integration. Works like a charm!
This change adds a gtest fixture for the EditlineTest
common setup and teardown code.
llvm-svn: 258565
This is a rather unhelpful warning indicating that the ternary operator return
types are mismatched, returning an integer and an enumeral type. Since the
integeral type is shorter to type, cast the enumeral type to `int`. Silences
the -Wextra warning from GCC.
llvm-svn: 258548
Address a couple of instances of -Wreturn-type warning from GCC. The switches
are covered, add an llvm_unreachable to the end of the functions to silence the
warning. NFC.
llvm-svn: 258546
Unfortunately, this turns out not to be working on the lldb-server tests, as there the server is
started in a different way. Since this was a bit of a hack to start with, I am removing it until
I can solve the problem more holistically.
llvm-svn: 258501
SUMMARY:
The symbol "$" has a special meaning for MIPS i.e it is marker for temporary symbols for MIPS.
So this patch uses additional _ prefix for "$__lldb_valid_pointer_check" so that it wont be marked as temporary symbol in case of MIPS.
Reviewers: clayborg, spyffe
Subscribers: dean, emaste, mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential http://reviews.llvm.org/D14111
llvm-svn: 258485
A lot of C code uses code like:
typedef struct
{
int a;
} FooType;
This creates debug info with an anonymous struct (a DW_TAG_structure_type with no DW_AT_name) and then a DW_TAG_typedef that points to the anonymous structure type. When a typedef is from a module and clang uses -gmodules and -fmodules, then we can end up trying to resolve an anonymous structure type in a DWO symbol file. This doesn't work very well when the structuture has no name, so we now check if a typedef comes from a module, and we directly resolve the typedef type in the module and copy it over. The version we copy from the module of course is correctly able to find the structure in the DWO symbol file, so this fixes the issues we run into.
<rdar://problem/24092915>
llvm-svn: 258443
Starting with Windows 10, the Windows loader is itself multi-threaded,
meaning that the loader spins up a few threads to do process
initialization before it executes main. Windows delivers these
notifications asynchronously and they can come out of order, so
we can't be sure that the first thread we get a notification about
is actually the zero'th thread.
This patch fixes this by requesting the thread stopped at the
breakpoint that was specified, rather than getting thread 0 and
verifying that it is stopped at a breakpoint.
Differential Revision: http://reviews.llvm.org/D16247
llvm-svn: 258432
This fixes the `thread step-over` regression exposed by http://reviews.llvm.org/D16186 , which depends on the symbols having actual sizes. Nine tests on Windows had started failing as a result. They all work again with this fix.
Differential Revision: http://reviews.llvm.org/D16415
llvm-svn: 258429
Summary:
We already have the ability to collect the server logs when doing local debugging. This enables
the collection of remote logs as well. This relies on specifying a relative path "server.log" for
LLDB_DEBUGSERVER_LOG_FILE when starting remote platform. Since we always set the platform working
directory to a fresh folder to avoid conflicts, the actual file path will always be different and
we can pick the logs up from there.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16322
llvm-svn: 258414
set the triple's "vendor" field to Apple.
We don't want to assume a vendor of Apple for all Mach-O files -
this breaks x86_64 EFI debugging where they put non-Apple binaries
in a Mach-O format for ease of handling.
But on armv7, Apple's ABI always uses r7 as the frame pointer
register; if we don't set the Vendor field to Apple, we can pick
up a generic armv7 ABI where the fp is r11 (or r7 for thumb) which
breaks backtracing altogether.
Greg is reluctant for us to make any assumptions about the Vendor
here, but we'll see how this shakes out. It's such a big problem
on armv7 if we don't know this is using the Apple ABI that it's worth
trying this approach.
<rdar://problem/22137561>
llvm-svn: 258387
On Mac OS X, this was working just fine in debug builds (presumably, because the right value ended up being at the right location for the variadic ABI), but not in Release builds
As a result, we were seeing failures with commands that set their own immediate output stream - only in Release builds, which always makes for a fun little investigation
I have removed those fcntl() calls and replaced them with dup() calls. This fixes the issue in both Debug and Release builds
llvm-svn: 258367
We had some #ifdefs that were looking for the wrong #defines and as a result
debugserver didn't have support for certain simulators. This patch resolves
the problem.
llvm-svn: 258365
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
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
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
The logic for skipping over the stop-and-restart events was incorrect as it was also skipping the
expectations. Implement it properly. No test is affected by this as they were not encountering
these events, but I encountered this issue when trying to use this function in a new test.
llvm-svn: 256928
This patch eases the printing of iterable string containers.
Author: Luke Drummond <luke.drummond@codeplay.com>
Differential Revision: http://reviews.llvm.org/D15773
llvm-svn: 256927
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/D15886
llvm-svn: 256915
One example where this occurs in practice is starting the Swift REPL and typing ":command history" since REPL commands aren't stored in the LLDB command prompt history.
llvm-svn: 256888
Tamas Berghammer