| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 355843
|
|
|
|
|
|
| |
This changes '@' prefix to '\'.
llvm-svn: 355841
|
|
|
|
| |
llvm-svn: 355838
|
|
|
|
| |
llvm-svn: 355830
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Apparently the problem is harder than anticipated. Skip the test for
now to fix buildbots.
llvm-svn: 355750
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
get_llvm_bin_dirs().
llvm-svn: 355661
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
In an attempt to understand why the test is still failing after r355555,
add some logging.
llvm-svn: 355647
|
|
|
|
|
|
|
| |
It looks like the simctl tool shipped in Xcode10.2 changed the format of
its json output.
llvm-svn: 355644
|
|
|
|
|
|
|
| |
Turns out this is actually testing that editline doesn't
screw up the terminal.
llvm-svn: 355640
|
|
|
|
| |
llvm-svn: 355615
|
|
|
|
|
|
|
| |
Tests that check the output of `memory find` may trip over
unreadable characters, and in Python 3 this is an error.
llvm-svn: 355612
|
|
|
|
|
|
|
| |
Recent versions of llvm monorepo builds build libc++abi.dylib as libc++abi.1.dylib.
This accespts both variants.
llvm-svn: 355571
|
|
|
|
| |
llvm-svn: 355548
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
built-in during expression parsing
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
|
|
|
|
|
|
| |
These tests are flakey on Windows and recently they have started failing AND also hanging the whole suite when they fail.
llvm-svn: 355443
|
|
|
|
|
|
|
| |
This passes locally but breaks on the bots. Maybe an SDK difference.
Reverting while I investigate.
llvm-svn: 355415
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test expect sample executable code be built, but fails on Windows.
Review comment https://reviews.llvm.org/D57689#1418597
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D57689
llvm-svn: 355413
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Based on https://gist.github.com/thlorenz/30bf0a3f67b1d97b2945#patching-and-rebuilding
The functionality was disabled at https://github.com/llvm/llvm-project/commit/521c2278abb16f0148cef1bd061cadb01ef43192
Reviewers: jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D57689
llvm-svn: 355402
|
|
|
|
| |
llvm-svn: 355356
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
symlinked build dir
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
|
|
|
|
|
|
|
| |
I see a test failing on the macOS bots. I can't reproduce
locally, so try to get the bots green before I can investigate.
llvm-svn: 354540
|
|
|
|
| |
llvm-svn: 354506
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Its functionality is entirely covered by exec-run.test (which
doesn't use pexpect)
Reviewers: serge-sans-paille
Subscribers: ki.stfu, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58459
llvm-svn: 354494
|
|
|
|
| |
llvm-svn: 354483
|
|
|
|
| |
llvm-svn: 354418
|
|
|
|
| |
llvm-svn: 354415
|
|
|
|
| |
llvm-svn: 354414
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 354297
|
|
|
|
| |
llvm-svn: 354286
|
|
|
|
|
|
|
| |
It turns out all that was needed to get this test passing was to fix the
python3 incompatibility.
llvm-svn: 354278
|