While reviewing D56233 it became clear to me that this test can be
simplified. There's no need for a start-stop cycle in the inferior -- we
can start fiddling with its registers as soon as it is launched.
llvm-svn: 357451
Summary:
This change prevents the lldb-vscode test harness from hanging up waiting for
new messages when the lldb-vscode subprocess crashes.
Now, when an EOF from the subprocess pipe is detected we enqueue a `None` packet
in the received packets list. Then, during the message processing loop, we can
use this `None` packet to tell apart the case where lldb-vscode has terminated
unexpectedly from the normal situation where no pending messages means blocking
and waiting for more data.
I believe this should be enough to fix the issues with these tests hanging on
multiple platforms. Once this lands, I'll prepare and test a separate change
removing the @skipIfLinux annotations.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D59849
llvm-svn: 357426
Summary:
In case of a breakpoint site overlapping with the destination address,
the WriteMemory method reported an incorrect memory size.
Instead of returning the right amount of bytes written, it falls through
the scope and returned 0.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Reviewers: jasonmolenda, friss, jingham
Subscribers: JDevlieghere, davide, lldb-commits, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60022
llvm-svn: 357420
Include support for NetBSD core dumps from evbarm/aarch64 system,
and matching test cases for them.
Based on earlier work by Kamil Rytarowski.
Differential Revision: https://reviews.llvm.org/D60034
llvm-svn: 357399
It was making a list of a certain size but not always filling in that
many elements, which would lead to a crash iterating over the list.
Differential Revision: https://reviews.llvm.org/D59913
llvm-svn: 357207
The changes were reverted due to ubsan errors (unaligned accesses). Here
I fix those errors by first copying the data into aligned storage.
Besides fixing alignment issues, this also fixes reading of minidump
strings on big-endian systems.
llvm-svn: 356896
This reverts the following two commits:
Revert "Extend r356573 (minidump UUID handling) to cover elf build-ids too"
Revert "Fix UUID decoding from minidump files"
Greg's original commit broke the sanitizer bot which has been red for
several days now.
http://green.lab.llvm.org/green/view/LLDB/job/lldb-sanitized/
llvm-svn: 356806
Breakpad (but not crashpad) will insert an empty (all-zero) build-id
record for modules which do not have a build-id. This tells lldb to
treat such records as empty/invalid uuids.
llvm-svn: 356751
This patch fixes:
UUIDs now don't include the age field from a PDB70 when the age is zero. Prior to this they would incorrectly contain the zero age which stopped us from being able to match up the UUID with real files.
UUIDs for Apple targets get the first 32 bit value and next two 16 bit values swapped. Breakpad incorrectly swaps these values when it creates darwin minidump files, so this must be undone so we can match up symbol files with the minidump modules.
UUIDs that are all zeroes are treated as invalid UUIDs. Breakpad will always save out a UUID, even if one wasn't available. This caused all files that have UUID values of zero to be uniqued to the first module that had a zero UUID. We now don't fill in the UUID if it is all zeroes.
Added tests for PDB70 and ELF build ID based CvRecords.
Differential Revision: https://reviews.llvm.org/D59433
llvm-svn: 356573
Python 3 default encoding is utf-8, so taking random bytes and
interpreting them as a string might result in invalid unicode sequences.
As the only thing we care about here is that the formatter shows the
elements of the underyling array, relax the string matching (this is
good enough as all the elements are distinct so they resolve to different
strings).
llvm-svn: 356096
Given this was under trace, it can just be removed. If somebody
ever needs to debug this testcase again and print the data, they
can add a new statement.
llvm-svn: 355999
Summary:
This patch is the MVP version of importing the std module into the expression parser to improve C++ debugging.
What happens in this patch is that we inject a `@import std` into our expression source code. We also
modify our internal Clang instance for parsing this expression to work with modules and debug info
at the same time (which is the main change in terms of LOC). We implicitly build the `std` module on the first use. The
C++ include paths for building are extracted from the debug info, which means that this currently only
works if the program is compiled with `-glldb -fmodules` and uses the std module. The C include paths
are currently specified by LLDB.
I enabled the tests currently only for libc++ and Linux because I could test this locally. I'll enable the tests
for other platforms once this has landed and doesn't break any bots (and I implemented the platform-specific
C include paths for them).
With this patch we can now:
* Build a libc++ as a module and import it into the expression parser.
* Read from the module while also referencing declarations from the debug info. E.g. `std::abs(local_variable)`.
What doesn't work (yet):
* Merging debug info and C++ module declarations. E.g. `std::vector<CustomClass>` doesn't work.
* Pretty much anything that involves the ASTImporter and templated code. As the ASTImporter is used for saving the result declaration, this means that we can't
call yet any function that returns a non-trivial type.
* Use libstdc++ for this, as it requires multiple include paths and Clang only emits one include path per module. Also libstdc++ doesn't support Clang modules without patches.
Reviewers: aprantl, jingham, shafik, friss, davide, serge-sans-paille
Reviewed By: aprantl
Subscribers: labath, mgorny, abidh, jdoerfert, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D58125
llvm-svn: 355939
Summary:
This patch marks the inline namespaces from DWARF as inline and also ensures that looking
up declarations now follows the lookup rules for inline namespaces.
Reviewers: aprantl, shafik, serge-sans-paille
Reviewed By: aprantl
Subscribers: eraman, jdoerfert, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D59198
llvm-svn: 355897
There was a crash that would happen if an IDE would ask for a child of a shared pointer via any SB API call that ends up calling StackFrame::GetValueForVariableExpressionPath(). The previous code expects an error to be set describing why the synthetic child of a type was not able to be found, but we have some synthetic child providers that weren't setting the error and returning an empty value object shared pointer. This fixes that to ensure we don't lose our debug session by crashing, fully tests GetValueForVariableExpressionPath functionality, and ensures we don't crash on GetValueForVariableExpressionPath() in the future.
Differential Revision: https://reviews.llvm.org/D59200
llvm-svn: 355850
Fix 2lwp_process_SIGSEGV NetBSD core test to terminate inside regular
function rather than libc call, in order to get reproducible backtrace
on different platforms.
Differential Revision: https://reviews.llvm.org/D59177
llvm-svn: 355786
Adjust the XFAIL-ing tests to match consistent results from buildbot.
I'm going to work on differences between them and my local results
following this.
llvm-svn: 355774
The code commited in r355764 didn't do what I want as I typed GetThreadID
instead of GetQueueID. This commit contains a (hopefully) better version
of the workaround.
llvm-svn: 355766
This is not a fix, but if I understand enough of the issue, it should
bail out early of the test when in a situation that would result in
a failure down the road.
llvm-svn: 355764
Fix the NetBSD core test not to verify libc function names in backtrace.
This obviously requires the same libc.so as originally used to produce
the core file, and so it is going to fail everywhere except on my
system.
llvm-svn: 355747
Improve the support for processing NetBSD cores. Fix reading process
identifier, thread information and associating the terminating signal
with the correct thread.
Includes test cases for single-threaded program receiving SIGSEGV,
and two dual-threaded programs: one where thread receives the signal,
and the other one when the whole process is signalled.
Differential Revision: https://reviews.llvm.org/D32149
llvm-svn: 355736
The last round of logging taught us that when the test fails, lldb
is indeed aware of the thread it's failing to associate to a given
queue. Add more logging to try to figure out why the thread and the
queue do not appear related to the Queue APIs.
llvm-svn: 355706
I committed an implementation of GetClangResourceDir on windows but
forgot to update this test. I merged the tests like I intended to, but I
realized that the test was actually failing. After looking into it, it
appears that FileSystem::Resolve was taking the path and setting
the FileSpec's Directory to "/path/to/lldb/lib/clang/" and the File to
"9.0.0" which isn't what we want. So I removed the resolve line from
DefaultComputeClangResourceDir.
llvm-svn: 355648
Core files need to know the size of the PRSTATUS header so that we can grab the register values that follow it. The code that figure out this size was using a hard coded list of architecture cores instead of relying on 32 or 64 bit for most cores.
The fix here fixes core files for 32 bit ARM. Prior to this the PRSTATUS header size was being returned as zero and the register values were being taken from the first bytes of the PRSTATUS struct (signo, etc).
Differential Revision: https://reviews.llvm.org/D58985
llvm-svn: 355526
Summary: This tests a fix in the ASTImpoter.cpp to ensure that we import built-in correctly,
see differential: https://reviews.llvm.org/D58743
Once this change is merged this test should pass and should catch regressions in this feature.
Differential Revision: https://reviews.llvm.org/D58790
llvm-svn: 355525
Pass appropriate -L and -Wl,-rpath flags pointing out to the LLVM
library directory on NetBSD. This is necessary since clang on NetBSD
requires libc++ but it is not installed as part of the system
by default. For the purpose of running buildbot, we want LLDB to use
just-built libc++.
Differential Revision: https://reviews.llvm.org/D58630
llvm-svn: 355502
Summary:
I'm doing this because I plan on implementing `ComputeClangResourceDirectory`
on windows so that `GetClangResourceDir` will work. Additionally, I made
test_paths make sure that the directory member of the returned FileSpec is not
none. This will fail on windows since `ComputeClangResourceDirectory` isn't
implemented yet.
Differential Revision: https://reviews.llvm.org/D58748
llvm-svn: 355463
Add a convenience 'expectedFailureNetBSD' decorator and mark all tests
currently failing on NetBSD with it. Also skip a few tests that hang
the test suite. This should establish a baseline for the test suite
and get us closer to enabling tests on buildbot. This will help us
catch regressions while we still have a lot of work to do to get tests
working.
It seems that there are also some flaky tests. I am going to address
them later on.
Differential Revision: https://reviews.llvm.org/D58527
llvm-svn: 355320
Remove the code forcing -stdlib=libstdc++ on NetBSD in getBuildFlags()
method. NetBSD uses libc++ everywhere else, and using libstdc++ here
causes lang/cpp/dynamic-value to fail to build.
Differential Revision: https://reviews.llvm.org/D58871
llvm-svn: 355273
Traditionally objc had two entry points, objc_msgSend for scalar
return methods, and objc_msgSend_stret for struct return convention
methods. But on arm64 the second was not needed (since arm64 doesn't
use an argument register for the struct return pointer) so it was removed.
The code that dispatches to the objc object checker when it sees some
flavor of objc_msgSend was not aware of this change so was sending the
wrong arguments to the checker.
<rdar://problem/48315890>
Differential Revision: https://reviews.llvm.org/D58699
llvm-svn: 355026
It turns out these tests actually succeed, if one has a clang with
address sanitizer support enabled (i.e., has enabled the compiler-rt
project). I guess none of the linux lldb devs have done that until now.
llvm-svn: 354976
The deserializer was not handling this case. For now we just
accept the absent option, and set it to the breakpoint default.
This will be more important if/when I figure out how to serialize
the options set on breakpont locations.
<rdar://problem/48322664>
llvm-svn: 354702
Fix the load_* using test Makefiles not to link -ldl on NetBSD.
There is no such a library on NetBSD, and dlopen() is available
without a library. Quoting the manpage:
(These functions are not in a library. They are included in every
dynamically linked program automatically.)
To resolve this portably, introduce a new USE_LIBDL option. If it set
to 1, Makefile.rules automatically appends -ldl on platforms needing it.
Differential Revision: https://reviews.llvm.org/D58517
llvm-svn: 354617
Getting failure when building in a directory which is symlinked elsewhere:
Failing Tests (1):
lldb-Suite :: functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.py
lldb-Suite :: source-manager/TestSourceManager.py
For TestCompDirSymLink:
------------------------------------------------------------------------------
runCmd: file .../lldb-test-build.noindex/functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.test_symlink_paths_set_procselfcwd_dwarf/CompDirSymLink
output: Current executable set to '.../lldb-test-build.noindex/functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.test_symlink_paths_set_procselfcwd_dwarf/CompDirSymLink' (x86_64).
runCmd: settings set plugin.symbol-file.dwarf.comp-dir-symlink-paths /proc/self/cwd
output: None
runCmd: breakpoint set -f ".../lldb-test-build.noindex/functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.test_symlink_paths_set_procselfcwd_dwarf/relative.cpp" -l 11
output: Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
It is because /proc/self/cwd (used above for plugin.symbol-file.dwarf.comp-dir-symlink-paths) points to an already resolved directory:
(cd /tmp;mkdir real;ln -s real symlink;cd symlink;ls -l /proc/self/cwd)
lrwxrwxrwx 1 jkratoch jkratoch 0 Feb 20 19:55 /proc/self/cwd -> /tmp/real/
------------------------------------------------------------------------------
For TestSourceManager the resolving is done by 'make -C' as found by Pavel Labath.
Differential Revision: https://reviews.llvm.org/D58465
llvm-svn: 354556
encode/decode the data before sending it over the socket. Since (AFAICT)
the vscode protocol (unlike the gdb-remote one) is fully textual, using
the utf8 codec here is appropriate.
llvm-svn: 354308
Summary:
The compilation of the TestDataFormatterLibcxxListLoop.py currently fails with this error:
```
functionalities/data-formatter/data-formatter-stl/libcxx/list/loop/main.cpp:19:24: error: no member named '__value_' in 'std::__1::__list_node_base<int, void *>'
assert(third_elem->__value_ == 3);
~~~~~~~~~~ ^
```
It seems the internal structure of list has changed with the 3.8 release. This patch makes the test compile with the current libc++ and with the previous libc++.
Reviewers: shafik, zturner, labath
Reviewed By: labath
Subscribers: christof, jdoerfert, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D58273
llvm-svn: 354202
test/lang/cpp/class-template-parameter-pack/TestClassTemplateParameterPack.py
It fails on Mac OS; apparently a VarDecl 'void *&C' is implicitly
declared there, making the class template name C ambiguous.
llvm-svn: 354185
This applies the same fix that was done in r354106 to the lldb-server
test: bitcasting the string to a bytes object before sending it over a
socket. Since the gdb-remote protocol occasionally contains binary data,
and it does not assign any particular encoding to them, this is the
right thing to do here.
llvm-svn: 354114
Summary:
This patch finishes the python3-ification of the lldb-server test suite.
It reverts the partial attempt in r352709 to encode/decode the string
via utf8 before writing to the socket. This wasn't enough because the
gdb-remote protocol can sometimes (but not very often) carry binary
data, and the utf8 codec chokes on that. Instead I add utility functions
to the "seven" module for performing "identity" transformations on the
byte data. This basically drills back the hole in the python type system
that the string/bytes distinction was supposed to plug. That is not
ideal, but was the best solution of the alternatives I could come up
with. The options I considered were:
- make use of the type system to add type safety to the test suite: This
required making a lot of changes to the test suite, since most of the
strings would now become byte objects instead, and it was not even
fully clear to me where to draw the line. One extreme solution would
be to just use byte objects everywhere, as the protocol doesn't
support non-ascii characters anyway. However, this appeared to be:
a) weird, because most of the protocol actually deals with strings,
but we would have to prefix everything with 'b'
b) clunky, because the handling of the bytes objects is sufficiently
different in PY2 and PY3 (e.g. b'a'[0] is a string in PY2, but an
int in PY3).
- using the latin1 codec (which gives an identity transformation for the
first 256 code points of unicode) instead of the custom
bytes_to_string functions. This almost could work, but it was still
slightly different between python 2 and 3, because in PY2 in would
return a unicode object, which would then cause problems when
combined with regular strings if it contained 8-bit chars.
With this in mind, I think the best solution for the time being is to
just coerce everything into the string type as early as possible, and
have things proceed indentically on both python versions. Once we stop
supporting python3, we can revisit the idea of using bytes objects more
prevasively.
Reviewers: davide, zturner, serge-sans-paille
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D58177
llvm-svn: 354106
Summary:
Instead of doing string chopping on the resulting python file, get swig
to output the version for us. The two things which make slightly
non-trivial are:
- in order to get swig to expand SWIG_VERSION for us, we cannot use
%pythoncode directly, but we have to go through an intermediate macro.
- SWIG_VERSION is a hex number, but it's components are supposed to be
interpreted decimally, so there is a bit of integer magic needed to
get the right number to come out.
I've tested that this approach works both with the latest (3.0.12) and
oldest (1.3.40) supported swig.
Reviewers: zturner, jingham, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58172
llvm-svn: 354104
dotest's version comparision function is just a lexicographical compare
of the version strings. This is obviously wrong. This patch implements
the comparison using distutils.version.LooseVersion as suggested by
Zachary.
Reviewers: zturner, labath, serge-sans-paille
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D58219
llvm-svn: 354047
This patch properly extracts the full submodule path as well as its
search paths from DWARF import decls and passes it on to the
ClangModulesDeclVendor.
rdar://problem/47970144
Differential Revision: https://reviews.llvm.org/D58090
llvm-svn: 353961
It looks like I was too hasty to submit the previous patch. It does fix
some tests on python3, but it also breaks one tests with python2.
This happens because the gdb-remote protocol can sometimes (but not very
often) contain binary data, and attempting to parse this as utf8
characters fails.
This reverts commit r353944.
llvm-svn: 353945
An equivalent change was made to RemapPaths, but it needed to be made
here as well. Also added a test for this and made the setup a little
more complex to avoid false successes.
<rdar://problem/47642498>
Differential Revision: https://reviews.llvm.org/D57552
llvm-svn: 353243
Summary:
This patch adds support of expression evaluation in a context of some object.
Consider the following example:
```
struct S {
int a = 11;
int b = 12;
};
int main() {
S s;
int a = 1;
int b = 2;
// We have stopped here
return 0;
}
```
This patch allows to do something like that:
```
lldb.frame.FindVariable("s").EvaluateExpression("a + b")
```
and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be
used (not locals `a` and `b`).
This is achieved by replacing of `this` type and object for the expression. This
has some limitations: an expression can be evaluated only for values located in
the debuggee process memory (they must have an address of `eAddressTypeLoad`
type).
Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille
Reviewed By: jingham
Subscribers: abidh, lldb-commits, leonid.mashinskiy
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D55318
llvm-svn: 353149
One considers it integer division, the other doesn't.
Move to `//` (floor division) so that this test passes
independently from the version.
llvm-svn: 352706
Summary:
When we are creating a ClassTemplateSpecializationDecl in ParseTypeFromDWARF(...) we are not handling the case where variadic pack is empty in the specialization. This patch handles that case and adds a test to prevent future regressions.
Differential Revision: https://reviews.llvm.org/D57363
llvm-svn: 352677
This fixes most references to the paths:
llvm.org/svn/
llvm.org/git/
llvm.org/viewvc/
github.com/llvm-mirror/
github.com/llvm-project/
reviews.llvm.org/diffusion/
to instead point to https://github.com/llvm/llvm-project.
This is *not* a trivial substitution, because additionally, all the
checkout instructions had to be migrated to instruct users on how to
use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of
checking out various projects into various subdirectories.
I've attempted to not change any scripts here, only documentation. The
scripts will have to be addressed separately.
Additionally, I've deleted one document which appeared to be outdated
and unneeded:
lldb/docs/building-with-debug-llvm.txt
Differential Revision: https://reviews.llvm.org/D57330
llvm-svn: 352514
When running the test suite on macOS with Python 3 we noticed a
difference in behavior between Python 2 and Python 3 for
seven.get_command_output. The output contained a newline with Python 3,
but not for Python 2. This resulted in an invalid SDK path passed to the
compiler.
Differential revision: https://reviews.llvm.org/D57275
llvm-svn: 352397
This makes it easier to exclude the test n bots that test earlier
DWARF formats, also it feels like this is the better decision for this
testcase anyway.
llvm-svn: 352111
We figured out the issue so the logging is no longer necessary. It turns
out we were using a session format that was not unique for inline tests.
llvm-svn: 351902
The new LLVM header is one line shorter than the old one, which lead to
some test failures. Ideally tests should rely on line numbers for
breakpoints or output, but that's a different discussion. Hopefully this
turns the bots green again.
llvm-svn: 351779
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
We're seeing an odd issue on GreenDragon's lldb-cmake-matrix. Dotest is
unable to move a log file (OSError: [Errno 2] No such file or
directory). The os.rename call is guarded with a check that the source
file and destination directory exist.
This wraps the call in a try-except that prints the source and
destination path to see which component seemingly doesn't exist.
llvm-svn: 351611
This patch changes the behavior when printing C++ function references:
where we previously would get a <could not determine size>, there is
now a <no summary available>. It's not clear to me whether this is a
bug or an omission, but it's one step further than LLDB previously
got.
Differential Revision: https://reviews.llvm.org/D56798
llvm-svn: 351376
Summary:
This patch allows to retrieve an address object for `ValueObject`'s children
retrieved through e.g. `GetChildAtIndex` or `GetChildMemberWithName`. It just
uses the corresponding method of the implementation object `m_impl` to achieve
that.
Reviewers: zturner, JDevlieghere, clayborg, labath, serge-sans-paille
Reviewed By: clayborg
Subscribers: leonid.mashinskiy, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D56147
llvm-svn: 351065
Summary:
In python 2, strings and bytes are the same, but they're not in
python 3, hence the return of read() needs an explicit conversion.
While I'm around, rename the return of Popen() from `pipe` to
`process`, as that's what Popen returns.
Reviewers: JDevlieghere, friss, zturner, aprantl, serge-sans-paille
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D56517
llvm-svn: 350788
There is already in use:
lit/lit-lldb-init:
settings set symbols.enable-external-lookup false
packages/Python/lldbsuite/test/lldbtest.py:
self.runCmd('settings set symbols.enable-external-lookup false')
But those are not in effect during MI part of the testsuite. Another problem is
that symbols.enable-external-lookup (read by GetEnableExternalLookup) has been
currently read only by LocateMacOSXFilesUsingDebugSymbols and therefore it had
no effect on Linux.
On Red Hat platforms (Fedoras, RHEL-7) there is DWZ in use and so
MiSyntaxTestCase-test_lldbmi_output_grammar FAILs due to:
AssertionError: error: inconsistent pattern ''^.+?\n'' for state 0x5f
(matched string: warning: (x86_64) /lib64/libstdc++.so.6 unsupported
DW_FORM values: 0x1f20 0x1f21
It is the only testcase with this error. It happens due to:
(lldb) target create "/lib64/libstdc++.so.6"
Current executable set to '/lib64/libstdc++.so.6' (x86_64).
(lldb) b main
warning: (x86_64) /lib64/libstdc++.so.6 unsupported DW_FORM values: 0x1f20 0x1f21
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
which happens only with gcc-base-debuginfo rpm installed (similarly for other packages).
It should also speed up the testsuite as it no longer needs to read
/usr/lib/debug symbols which have no effect (and should not have any effect) on
the testsuite results.
Differential Revision: https://reviews.llvm.org/D55859
llvm-svn: 350368
TestQueues is failing randomly on green dragon and I suspect it is
because the enqueued threads haven't executed by the time we expect
them. This patch adds file-based synchronization to the queues.
Differential Revision: https://reviews.llvm.org/D56208
llvm-svn: 350247
python 3.7 removes re._pattern_type. Fix the one place where we were
depending on the type of regular expressions to compute the type
dynamically.
llvm-svn: 350093
They both run the same command, and people get used to typing the shortest
string they can, so we should support alias info on shortened strings as well.
<rdar://problem/46859207>
llvm-svn: 349874
These are tests that found actual, but hard to fix, bugs that are
tracked elsewhere. Leaving them red only distracts from new failures
this bot finds.
llvm-svn: 349851
This is a set of tests that were all marked as failing becuse of pr24764. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349719
This builds on https://reviews.llvm.org/D43884 and https://reviews.llvm.org/D43886 and extends LLDB support of Obj-C exceptions to also look for a "current exception" for a thread in the C++ exception handling runtime metadata (via call to __cxa_current_exception_type). We also construct an actual historical SBThread/ThreadSP that contains frames from the backtrace in the Obj-C exception object.
The high level goal this achieves is that when we're already crashed (because an unhandled exception occurred), we can still access the exception object and retrieve the backtrace from the throw point. In Obj-C, this is particularly useful because a catch+rethrow is very common and in those cases you currently don't have any access to the throw point backtrace.
Differential Revision: https://reviews.llvm.org/D44072
llvm-svn: 349718
This is a set of tests that were all marked as failing becuse of several different bugs. A couple of the bugs are now resolved as fixed since all the tests that were failing associated with the bug are now passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349713
This is a set of tests that were all marked as failing becuse of several different bugs. A couple of the bugs are now resolved as fixed since all the tests that were failing associated with the bug are now passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349711
This is a set of tests that were all marked as failing becuse of pr21765. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349668
This is a set of tests that were all marked as failing becuse of pr24489. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349665
Prior to this change we would show the name of the section that a memory region belonged to but not its actual region name. Now we show this,. Added a test that reuses the regions-linux-map.dmp minidump file to test this and verify the correct region names for various memory regions.
Differential Revision: https://reviews.llvm.org/D55854
llvm-svn: 349658
Currently spawnLldbMi accepts both lldb-mi options and executable to debug as
a single parameter. Split them.
As in D55859 we will need to execute one lldb-mi command before loading the
exe. Therefore we can no longer use the exe as lldb-mi command-line parameter
as then there is no way to execute a command before loading exe specified as
lldb-mi command-line parameter.
LocateExecutableSymbolFileDsym should be static, that is also a little
refactorization.
Differential Revision: https://reviews.llvm.org/D55858
llvm-svn: 349607
the "self.assertEqual(thread.GetStopReason(), lldb.eStopReasonSignal)"
was occasionally failing because the stop reason would come out as
"trace" this happened if we issued the interrupt just as the processed
stopped due to single-stepping over the breakpoint (i.e., the it was not
necessary to send any signal).
Fix this by removing the breakpoint before resuming the process. This
ensures the process can run unobstructed.
After this, the test passed 200 consecutive runs successfully for me,
even while the system was under heavy load.
llvm-svn: 349491
This test was disabled in r326756 as a part of "upstreaming debugserver
support for AVX-512 (zmm register set)". This looks like an error
because both register set and remote stubs are different.
In any case, the test passes now.
llvm-svn: 349485
This test is passing now on linux. The same test is claimed to be flaky
on darwin, so it's possible that's true on linux too. If that's the case
we'll have to skip it here too (or fix it).
I mark the test as not-debug-info-dependent as a drive-by.
llvm-svn: 349482
These tests are now passing on linux, at least with top-of-tree clang,
clang-6 and gcc-7.3. It's possible it may still be failing with some
older compilers, but I don't have those around to test.
llvm-svn: 349478
make the executable name more unique.
This test is failing sporadically on some bots. By removing the sleep
synchronisation, I'm hoping to get it to fail more reproducibly so I
can investigate what is going on.
llvm-svn: 349397
While I was out hunting for remaining pexpect-based tests, I came
across these tests that can't possibly work an any modern system, as
they rely on having gdb available in /Developer.
This patch simply removes the test without replacement.
Differential Revision: https://reviews.llvm.org/D55559
llvm-svn: 349194
This re-commits r348592, which was reverted due to a failing test on
macos.
The issue was that I was passing a null pointer for the
"CreateMemoryInstance" callback when registering ObjectFileBreakpad,
which caused crashes when attemping to load modules from memory. The
correct thing to do is to pass a callback which always returns a null
pointer (as breakpad files are never loaded in inferior memory).
It turns out that there is only one test which exercises this code path,
and it's mac-only, so I've create a new test which should run everywhere
(except windows, as one cannot delete an executable which is being run).
Unfortunately, this test still fails on linux for other reasons, but at
least it gives us something to aim for.
The original commit message was:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information
A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +
Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).
In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.
Reviewers: clayborg, zturner, lemo, amccarth
Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D55214
llvm-svn: 348773
Summary:
r348240 assumes that an expression contains the Objective C option if
Objective C Runtime is found. But on MacOS X it seems that the test application
process always contains Objective C Runtime, so the test fails when it assumes
that the language is C++ only. Skip this part on Darwin.
llvm-svn: 348250
Summary:
This patch adds the check of the language before ignoring names like `id` or
`Class`, which are reserved in Objective C, but are allowed in C++. It is needed
to make it possible to evaluate expressions in a C++ program containing names
like `id` or `Class`.
Reviewers: jingham, zturner, labath, clayborg
Reviewed By: jingham, clayborg
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D54843
llvm-svn: 348240
This patch changes the way the reproducer is initialized. Rather than
making changes at run time we now do everything at initialization time.
To make this happen we had to introduce initializer options and their SB
variant. This allows us to tell the initializer that we're running in
reproducer capture/replay mode.
Because of this change we also had to alter our testing strategy. We
cannot reinitialize LLDB when using the dotest infrastructure. Instead
we use lit and invoke two instances of the driver.
Another consequence is that we can no longer enable capture or replay
through commands. This was bound to go away form the beginning, but I
had something in mind where you could enable/disable specific providers.
However this seems like it adds very little value right now so the
corresponding commands were removed.
Finally this change also means you now have to control this through the
driver, for which I replaced --reproducer with --capture and --replay to
differentiate between the two modes.
Differential revision: https://reviews.llvm.org/D55038
llvm-svn: 348152
Summary:
This patch contains several small fixes, which makes it possible to evaluate
expressions on Windows using information from PDB. The changes are:
- several sanitize checks;
- make IRExecutionUnit::MemoryManager::getSymbolAddress to not return a magic
value on a failure, because callers wait 0 in this case;
- entry point required to be a file address, not RVA, in the ObjectFilePECOFF;
- do not crash on a debuggee second chance exception - it may be an expression
evaluation crash. Also fix detection of "crushed" threads in tests;
- create parameter declarations for functions in AST to make it possible to call
debugee functions from expressions;
- relax name searching rules for variables, functions, namespaces and types. Now
it works just like in the DWARF plugin;
- fix endless recursion in SymbolFilePDB::ParseCompileUnitFunctionForPDBFunc.
Reviewers: zturner, asmith, stella.stamenova
Reviewed By: stella.stamenova, asmith
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53759
llvm-svn: 348136
The test assumes that HW breakpoints are not implemented by the debug
server. Windows doesn't use these and might actually support HW
breakpoints so these tests are expected fail because they don't raise
the expected error.
llvm-svn: 348010
Summary:
This patch fixes the next situation. On Windows clang-cl makes no stub before
the main function, so the main function is located exactly on module entry
point. May be it is the same on other platforms. So consider the following
sequence:
- set a breakpoint on main and stop there;
- try to evaluate expression, which requires a code execution on the debuggee
side. Such an execution always returns to the module entry, and the plan waits
for it there;
- the plan understands that it is complete now and removes its breakpoint. But
the breakpoint site is still there, because we also have a breakpoint on
entry;
- StopInfo analyzes a situation. It sees that we have stopped on the breakpoint
site, and it sees that the breakpoint site has owners, and no one logical
breakpoint is internal (because the plan is already completed and it have
removed its breakpoint);
- StopInfo thinks that it's a user breakpoint and skips it to avoid recursive
computations;
- the program continues.
So in this situation the program continues without a stop right after
the expression evaluation. To avoid this an additional check that
the plan was completed was added.
Reviewers: jingham, zturner, boris.ulasevich
Reviewed by: jingham
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53761
llvm-svn: 347974
Earlier this month there was a change in clang that defaulted to using codeview rather than dwarf on Windows. Since all the tests rely on dwarf, we need to explicitly request dwarf when building on Windows.
llvm-svn: 347924
This adds new APIs and a command to deal with exceptions (mostly Obj-C exceptions): SBThread and Thread get GetCurrentException API, which returns an SBValue/ValueObjectSP with the current exception for a thread. "Current" means an exception that is currently being thrown, caught or otherwise processed. In this patch, we only know about the exception when in objc_exception_throw, but subsequent patches will expand this (and add GetCurrentExceptionBacktrace, which will return an SBThread/ThreadSP containing a historical thread backtrace retrieved from the exception object. Currently unimplemented, subsequent patches will implement this).
Extracting the exception from objc_exception_throw is implemented by adding a frame recognizer.
This also add a new sub-command "thread exception", which prints the current exception.
Differential Revision: https://reviews.llvm.org/D43886
llvm-svn: 347813
A couple of new tests have been added that use existing class names. This causes failures on Windows if the tests run at the same time and on any platform it results in the logs being overwritten.
llvm-svn: 347717
Summary: In order to invoke sed on Windows, we need to quote the command correctly. Since we already have commands which do that, move the definitions at the beginning of the file and then re-use them for each command.
Reviewers: aprantl, zturner
Subscribers: teemperor, lldb-commits
Differential Revision: https://reviews.llvm.org/D54709
llvm-svn: 347243
Those tests were using pexpect and being flaky on some of ours bots.
This patch reimplmeents the tests usinf FileCheck, and it also
extends the test coverage to a few more stop-hook options.
llvm-svn: 347109
This saves about 3 redundant gigabytes from the Objective-C test build
directories. Tests that must do unsavory things with the LLDB clang
module cache, already specify a per-test module cache in their .py
test instructions.
<rdar://problem/36002081>
Differential Revision: https://reviews.llvm.org/D54602
llvm-svn: 347057
Just to be safe, up until now each test used its own Clang module
cache directory. Since the compiler within one testsuite doesn't
change it is just as safe to share a clang module directory inside the
LLDB test build directory. This saves us from compiling tens of
gigabytes of redundant Darwin and Foundation .pcm files and also
speeds up running the test suite quite significantly.
rdar://problem/36002081
Differential Revision: https://reviews.llvm.org/D54601
llvm-svn: 347056
Summary:
This commit implements basic DidAttach and DidLaunch for the windows
DynamicLoader plugin which allow us to load shared libraries from the
inferior.
Reviewers: sas, zturner
Reviewed By: zturner
Differential Revision: https://reviews.llvm.org/D54544
llvm-svn: 346994
Summary:
Windows make will search for other shells and choose those over cmd
if available (e.g. C:\cygdrive\bin\sh.exe). This shell has numerous
issues with path handling (/ vs \\ vs \ and C:). So default to using
cmd.exe which is known to work.
Reviewers: zturner, sas, xiaobai
Reviewed By: zturner
Differential Revision: https://reviews.llvm.org/D54510
llvm-svn: 346993
Xcode 10 doesn't ship with an i386 SDK any more. This patch ports the
testcase from an i386/x86_64 -> x86_64/x86_64h universal binary.
rdar://problem/46099343
llvm-svn: 346981
When debugging read-only memory we cannot use software breakpoint. We
already have support for hardware breakpoints and users can specify them
with `-H`. However, there's no option to force LLDB to use hardware
breakpoints internally, for example while stepping.
This patch adds a setting target.require-hardware-breakpoint that forces
LLDB to always use hardware breakpoints. Because hardware breakpoints
are a limited resource and can fail to resolve, this patch also extends
error handling in thread plans, where breakpoints are used for stepping.
Differential revision: https://reviews.llvm.org/D54221
llvm-svn: 346920
An Obj-C array type _NSCallStackArray is used in NSException backtraces. This patch adds a synthetic frontend for _NSCallStackArray, which now correctly returns frame PCs.
Differential Revision: https://reviews.llvm.org/D44081
llvm-svn: 346708
This patch teaches LLDB about more fields on NSException Obj-C objects, specifically we can now retrieve the "name" and "reason" of an NSException. The goal is to eventually be able to have SB API that can provide details about the currently thrown/caught/processed exception.
Differential Revision: https://reviews.llvm.org/D43884
llvm-svn: 346695
This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
llvm-svn: 346626
qWatchpointSupportInfo packet correctly.
In GDBRemoteCommunicationClient::GetWatchpointSupportInfo,
if the response to qWatchpointSupportInfo does not
include the 'num' field, then we did not get an answer
we understood, mark this target as not supporting that
packet.
In Target.cpp, rename the very confusingly named
CheckIfWatchpointsExhausted to CheckIfWatchpointsSupported,
and check the error status returned by
Process::GetWatchpointSupportInfo. If we cannot determine
what the number of supported watchpoints are, assume that
they will work. We'll handle the failure
later when we try to create/enable the watchpoint if the
Z2 packet isn't supported.
Add a gdb_remote_client test case.
<rdar://problem/42621432>
llvm-svn: 346561
Clang recently improved its DWARF support for C VLA types. The DWARF
now looks like this:
0x00000051: DW_TAG_variable [4]
DW_AT_location( fbreg -32 )
DW_AT_name( "__vla_expr" )
DW_AT_type( {0x000000d3} ( long unsigned int ) )
DW_AT_artificial( true )
...
0x000000da: DW_TAG_array_type [10] *
DW_AT_type( {0x000000cc} ( int ) )
0x000000df: DW_TAG_subrange_type [11]
DW_AT_type( {0x000000e9} ( __ARRAY_SIZE_TYPE__ ) )
DW_AT_count( {0x00000051} )
Without this patch LLDB will naively interpret the DIE offset 0x51 as
the static size of the array, which is clearly wrong. This patch
extends ValueObject::GetNumChildren to query the dynamic properties of
incomplete array types.
See the testcase for an example:
4 int foo(int a) {
5 int vla[a];
6 for (int i = 0; i < a; ++i)
7 vla[i] = i;
8
-> 9 pause(); // break here
10 return vla[a-1];
11 }
(lldb) fr v vla
(int []) vla = ([0] = 0, [1] = 1, [2] = 2, [3] = 3)
(lldb) quit
rdar://problem/21814005
Differential Revision: https://reviews.llvm.org/D53530
llvm-svn: 346165
In January Davide sent an e-mail to the mailing list to suggest removing
unmaintained language plugins such as Go and Java. The plan was to have
some cool down period to allow users to speak up, however after that the
plugins were never actually removed.
This patch removes the Go debugger plugin.
The plugin can be added again in the future if it is mature enough both
in terms of testing and maintenance commitment.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html
Differential revision: https://reviews.llvm.org/D54057
llvm-svn: 346157
dotest.py started reporting:
Exception: Found multiple tests with the name TestSampleTest.py
After the commit of:
https://reviews.llvm.org/D54056
llvm-svn: 346089
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345693
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345686
This patch introduces a concept of "frame recognizer" and "recognized frame". This should be an extensible mechanism that retrieves information about special frames based on ABI, arguments or other special properties of that frame, even without source code. A few examples where that could be useful could be 1) objc_exception_throw, where we'd like to get the current exception, 2) terminate_with_reason and extracting the current terminate string, 3) recognizing Objective-C frames and automatically extracting the receiver+selector, or perhaps all arguments (based on selector).
Differential Revision: https://reviews.llvm.org/D44603
llvm-svn: 345678
Due to some libcxx changes to inlining, this now also crashes,
so it gets reported as "failure" by the bot. This commit doesn't
really change the status quo, just placates the bots.
llvm-svn: 345668
Add support in ProcessGDBRemote::GetGDBServerRegisterInfo
for recognizing a generic "arm" architecture that will be used if
nothing better is available so that we don't ignore the register
definitions if we didn't already have an architecture set.
Also in ProcessGDBRemote::DoConnectRemote don't set the target
arch unless we have a valid architecture to set it to.
Platform::ConnectProcess will try to get the current target's
architecture, or the default architecture, when creating the
target for the connection to be attempted. If lldb was started
with a target binary, we want to create this target with that
architecture in case the remote gdb stub doesn't supply a
qHostInfo arch.
Add logging to Target::MergeArchitecture.
<rdar://problem/34916465>
llvm-svn: 345106
Summary: These tests fail on Windows because of known limitations (a.k.a. bugs) with the current implementation of GetFrameAtIndex
Reviewers: asmith, vsk
Reviewed By: vsk
Subscribers: abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D53415
llvm-svn: 344788
Summary: They fail similarly to some of the other breakpoint tests on Windows, so I suspect the cause is the same. I've linked to the same bug.
Reviewers: asmith, zturner, jingham
Subscribers: abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D53331
llvm-svn: 344744
This reverts commit r344647.
This causes build failures with [-Werror, -Wswitch]. Some cases where the newly
introduced enum value is not handled in particular are in:
lldb/source/Expression/REPL.cpp:350
lldb/source/Interpreter/CommandInterpreter.cpp:1529
(maybe there could be more)
As I don't understand lldb to make sure the likely trivial fixes are
correct and also as they might need additional tests, leaving to the
author to resolve.
llvm-svn: 344722
Before we returned an error that was not exposed in the SB API and no useful
error message. This change returns eExpressionProducedNoResult and an
appropriate error string.
<rdar://problem/44539514>
Differential Revision: https://reviews.llvm.org/D53309
llvm-svn: 344647
tests when targetting a device. Add an include to
safe-to-call-func to work around a modules issue with
a certain combination of header files. Add rules for
Darwin systems to ad-hoc codesign binaries that the
testsuite builds.
llvm-svn: 344635
The TestTailCallFrameSBAPI.py test checks that function names in a
backtrace are equal to an expected value.
Use a relaxed substring check because function dislpay names are
platform-dependent. E.g we see "void sink(void)" on Windows, but "sink()" on
Darwin. This seems like a bug -- just work around it for now.
llvm-svn: 344634
Summary: On non-mac platforms, mac_ver returns an empty string which when converted to LooseVersion has no "version" property. This causes a failure when the decorator executes. Instead, check whether the value returned from mac_ver is an empty string and avoid the LooseVersion comparison.
Reviewers: labath, davide, asmith, shafik, jingham
Reviewed By: jingham
Subscribers: jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D53208
llvm-svn: 344623
Some tests in test/functionalities/tail_call_frames are failing on
non-Darwin platforms. Use assertEqual to improve logging on failure.
llvm-svn: 344581
Summary:
If the names are not unique, the tests overwrite each other's results and logs. This also causes failures on platforms where the files are locked for writing.
The names of the class/test pairs *have to* always be unique. The easiest way to achieve that is to name each class differently (usually the same as the file name).
Reviewers: jasonmolenda, asmith
Subscribers: clayborg, nemanjai, kbarton, lldb-commits
Differential Revision: https://reviews.llvm.org/D53297
llvm-svn: 344547
Summary: This test is failing on Windows because lldb does not support JIT on Windows.
Reviewers: davide, asmith
Reviewed By: davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D53226
llvm-svn: 344543
If the path was not specified (and it's None), lexists throws an exception rather than returning False. get_filecheck_path now checks whether filecheck is set before calling lexists
llvm-svn: 344410
This allows bots which haven't updated to pass in --filecheck to
dotest.py to run more tests. FileCheck-dependent tests will continue to
fail.
Differential Revision: https://reviews.llvm.org/D53175
llvm-svn: 344401
Summary: This is another string/byte conversion issue between Python 2 and 3. In Python 2, the subprocess communication expects a byte string, but in Python 3, it expects bytes. Since both versions are capable of using strings when universal_newlines is set to True AND filecheck operates on strings, force the use of strings.
Reviewers: zturner, asmith, vsk
Reviewed By: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D53166
llvm-svn: 344386
