| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
3.7"
llvm-svn: 355523
|
|
|
|
|
|
|
|
| |
On Windows, lldb::thread_t is just a void*, so the we will try to
allocate an object of type void when deserializing. Undef this for now
until we support void* arguments.
llvm-svn: 355519
|
|
|
|
|
|
| |
This should unbreak the Windows bot.
llvm-svn: 355518
|
|
|
|
| |
llvm-svn: 355510
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This file implements some general purpose data structures, and so it
belongs to the Utility module.
Reviewers: zturner, jingham, JDevlieghere, clayborg, espindola
Subscribers: emaste, mgorny, javed.absar, arichardson, MaskRay, lldb-commits
Differential Revision: https://reviews.llvm.org/D58970
llvm-svn: 355509
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DynamicLoaderDarwinKernel::SearchForKernelNearPC.
Currently when lldb might be doing a kernel debug session, it scans through
memory by taking the current pc value and looking for a kernel at megabyte
boundaries, up to 32MB behind $pc. This adjusts the algorithm to
scan back at every 16k page boundary and to stop scanning as soon
as we hit a memory read error. The addition of stopping at a memory read
error saves us from tons of unnecessary packet traffic on generic
targets where lldb might look for a kernel binary.
I've been trying to think of how to construct a test for this; it's a bit
tricky. A gdb-remote protocol test with the contents of a fake tiny kernel
mach-o binary would satisify part of it, but this kernel path also directly
calls over to dsymForUUID or DebugSymbols framework lookups to find the
kernel binary as well. I'll keep thinking about this one, but it's so
intertangled with these two external systems that it may be hard to do.
<rdar://problem/48578197>
llvm-svn: 355476
|
|
|
|
| |
llvm-svn: 355473
|
|
|
|
|
|
|
|
| |
The function signature of ComputeClangResourceDirectory for windows
wasn't updated when the others changed, causing the windows build to
fail. This should fix that.
llvm-svn: 355471
|
|
|
|
|
|
|
|
|
| |
Now that the LLDB instrumentation macros are in place, we should use
that to test reproducer replay.
Differential revision: https://reviews.llvm.org/D58565
llvm-svn: 355470
|
|
|
|
|
|
|
| |
With the reproducer logic in place for the command interpreter we no
longer need to make SBDebugger::SetInputFileHandle a no-op.
llvm-svn: 355469
|
|
|
|
| |
llvm-svn: 355466
|
|
|
|
|
|
| |
Forgot to undef this before landing.
llvm-svn: 355465
|
|
|
|
|
|
| |
Make sure the variable is used when asserts are compiled out.
llvm-svn: 355464
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
This patch adds the SBReproducer macros needed to capture and reply the
corresponding calls. This patch was generated by running the lldb-instr
tool on the API source files.
Differential revision: https://reviews.llvm.org/D57475
llvm-svn: 355459
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running the test suite with the instrumentation macros, I noticed
two lldb-mi tests regressed. The issue was the copy constructor of
SBLineEntry. Without the macros the returned value would be elided, but
with the macros the copy constructor was called. The latter using ::IsValid
to determine whether the underlying opaque pointer should be set. This
is likely a remnant of when ::IsValid would only check the validity of the
smart pointer. In SBLineEntry however, it actually forwards to
LineEntry::IsValid().
So what happened here was that because of the macros the copy
constructor was called. The opaque pointer was valid but the LineEntry
didn't consider itself valid. So the copied-to object ended up default
initialized.
This patch replaces all checks for IsValid in copy (assignment)
constructors with checks for the opaque pointer itself.
Differential revision: https://reviews.llvm.org/D58946
llvm-svn: 355458
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D58838
llvm-svn: 355457
|
|
|
|
|
|
| |
causing lldb-mi testsuite failures?
llvm-svn: 355449
|
|
|
|
|
|
| |
This test is also no longer reliably failing or passing on Windows and it is hanging every few runs.
llvm-svn: 355448
|
|
|
|
|
|
| |
These tests are flakey on Windows and recently they have started failing AND also hanging the whole suite when they fail.
llvm-svn: 355443
|
|
|
|
| |
llvm-svn: 355435
|
|
|
|
|
|
|
|
| |
https://reviews.llvm.org/D56913
rdar://problem/48568543
llvm-svn: 355422
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Testsuite hangs on Windows likely due to these changes.
llvm-svn: 355406
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intention in r355323 has been to implement a no-op resolver in the
HostInfoBase class, which will then be shadowed a an implementation in
the HostInfoPosix class. However, I add the shadowing declaration in
HostInfoPosix.h, and instead had implemented the HostInfoBase function
in HostInfoPosix.cpp. This has lead to undefined symbols on windows, and
a subsequent implementation of a no-op resolver in HostInfoWindows
(r355329).
Since now there is no point on having a no-op resolver in the base
class, I just remove the base declaration altogether, and have
HostInfoPosix implement the (newly-declared) HostInfoPosix version of
that function.
llvm-svn: 355398
|
|
|
|
| |
llvm-svn: 355392
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D58833
llvm-svn: 355388
|
|
|
|
| |
llvm-svn: 355375
|
|
|
|
|
|
|
| |
This revert the commit because it broke the bots. I need to find
a way that works with both versions.
llvm-svn: 355364
|
|
|
|
|
|
| |
Fixes three tests in the testsuite.
llvm-svn: 355359
|
|
|
|
| |
llvm-svn: 355358
|
|
|
|
| |
llvm-svn: 355356
|
|
|
|
|
|
|
| |
-> Add a missing include to find the base class.
-> Add a missing out-of-line declaration for a member function.
llvm-svn: 355353
|
|
|
|
|
|
|
|
| |
caused by https://reviews.llvm.org/D56913"
This reverts commit r355351.
llvm-svn: 355352
|
|
|
|
|
|
|
|
| |
https://reviews.llvm.org/D56913
rdar://problem/48568543
llvm-svn: 355351
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are set of classes in Target that describe the parameters of a
process - e.g. it's PID, name, user id, and similar. However, since it
is a bare description of a process and contains no actual functionality,
there's nothing specifically that makes this appropriate for being in
Target -- it could just as well be describing a process on the host, or
some hypothetical virtual process that doesn't even exist.
To cement this, I'm moving these classes to Utility. It's possible that
we can find a better place for it in the future, but as it is neither
Host specific nor Target specific, Utility seems like the most appropriate
place for the time being.
After this there is only 2 remaining references to Target from Host,
which I'll address in a followup.
Differential Revision: https://reviews.llvm.org/D58842
llvm-svn: 355342
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
clang-cl tries to match cl's interface, and treats /U as "Removes a
predefined macro" as cl does. When you feed clang-cl a file that begins with
'/U' (e.g. /Users/xiaobai/foo.c), clang-cl will emit a warning and in some cases
an error, like so:
clang-9: warning: '/Users/xiaobai/foo.c' treated as the '/U' option [-Wslash-u-filename]
clang-9: note: Use '--' to treat subsequent arguments as filenames
clang-9: error: no input files
If you're using clang-cl, make sure '--' is passed before the source file.
Differential Revision: https://reviews.llvm.org/D58860
llvm-svn: 355341
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].
I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.
[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html
Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille
Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits
Tags: #clang, #sanitizers, #lldb, #openmp, #llvm
Differential Revision: https://reviews.llvm.org/D58791
llvm-svn: 355340
|
|
|
|
|
|
|
|
|
| |
That patch added a function to HostInfo that returns an instance
of UserIDResolver, but this function was unimplemented on Windows,
leading to linker errors. For now, just return a dummy implementation
that doesn't resolve user ids to get the build green.
llvm-svn: 355329
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This creates an abstract base class called "UserIDResolver", which can
be implemented to provide user/group ID resolution capabilities for
various objects. Posix host implement a PosixUserIDResolver, which does
that using posix apis (getpwuid and friends). PlatformGDBRemote
forwards queries over the gdb-remote link, etc. ProcessInstanceInfo
class is refactored to make use of this interface instead of taking a
platform pointer as an argument. The base resolver class already
implements caching and thread-safety, so implementations don't have to
worry about that.
The main motivating factor for this was to remove external dependencies
from the ProcessInstanceInfo class (so it can be put next to
ProcessLaunchInfo and friends), but it has other benefits too:
- ability to test the user name caching code
- ability to test ProcessInstanceInfo dumping code
- consistent interface for user/group resolution between Platform and
Host classes.
Reviewers: zturner, clayborg, jingham
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D58167
llvm-svn: 355323
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use '127.0.0.1' instead of 'localhost' in ConnectLocally() function
as this is the specific address the server is bound to. Using
'localhost' may involve trying IPv6 first which may accidentally be used
by another service.
While technically it might be interesting to support IPv6 here, it would
need to be supported properly, with the connection copying family
and address from the listening socket, and possibly without relying
on existence of 'localhost' at all.
Differential Revision: https://reviews.llvm.org/D58883
llvm-svn: 355285
|
|
|
|
|
|
|
|
| |
This stanza was removed in r355213, but it seems that patch did not
fully fix the problem, as the test still fails sporadically
(particularly under heavy load) on linux.
llvm-svn: 355276
|
|
|
|
| |
llvm-svn: 355274
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
automatic move should not fire when returning type T in a function with
result type Expected<T>. Some compilers seem to allow that nonetheless.
llvm-svn: 355270
|