| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 280087
|
|
|
|
|
|
| |
This fixes the linux test suite.
llvm-svn: 280074
|
|
|
|
|
|
| |
llvm-using StringExtractor.cpp in the xcode project file settings.
llvm-svn: 280039
|
|
|
|
|
|
|
|
|
|
|
|
| |
StringExtractor::GetNameColonValue() looks for a substring of the
form "<name>:<value>" and returns <name> and <value> to the caller.
This results in two unnecessary string copies, since the name and
value are not translated in any way and simply returned as-is.
By converting this to return StringRefs we can get rid of hundreds
of string copies.
llvm-svn: 280000
|
|
|
|
|
|
|
|
|
|
|
| |
I have some improvements to make to StringExtractor that require
using LLVM. debugserver can't take a dependency on LLVM but uses
this file, so I'm forking it off into StdStringExtractor and
StringExtractor, so that StringExtractor can take advantage of
some performance improvements and readability improvements that
LLVM can provide.
llvm-svn: 279997
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
std::atomic<uint64_t> requires 64-bit alignment in order to
guarantee atomicity. Normally the compiler is pretty good about
aligning types, but an exception to this is when the type is
passed by value as a function parameter. In this case, if your
stack is 4-byte aligned, most modern compilers (including clang
as of LLVM 4.0) fail to align the type, rendering the atomicity
ineffective.
A deeper investigation of the class's implementation suggests
that the use of atomic was in vain anyway, because if the class
were to be shared amongst multiple threads, there were already
other data races present, and that the proper way to ensure
thread-safe access to this data would be to use a mutex from a
higher level.
Since the std::atomic was not serving its intended purpose anyway,
and since the presence of it generates compiler errors on some
platforms that cannot be workaround, we remove std::atomic from
Address here. Although unlikely, if data races do resurface
the proper fix should involve a mutex from a higher level, or an
attempt to limit the Address's access to a single thread.
llvm-svn: 279994
|
|
|
|
|
|
|
| |
There was some code that was ifdef'ed out that I didn't catch
in my earlier patch.
llvm-svn: 279920
|
|
|
|
|
|
|
|
| |
These are helpful on their own, but will be even more useful
once the GetNameColonValue is updated to return StringRefs
instead of std::strings.
llvm-svn: 279919
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This started as an effort to change StringExtractor to store a
StringRef internally instead of a std::string. I got that working
locally with just 1 test failure which I was unable to figure out the
cause of. But it was also a massive changelist due to a trickle
down effect of changes.
So I'm starting over, using what I learned from the first time to
tackle smaller, more isolated changes hopefully leading up to
a full conversion by the end.
At first the changes (such as in this CL) will seem mostly
a matter of preference and pointless otherwise. However, there
are some places in my larger CL where using StringRef turned 20+
lines of code into 2, drastically simplifying logic. Hopefully
once these go in they will illustrate some of the benefits of
thinking in terms of StringRef.
llvm-svn: 279917
|
|
|
|
| |
llvm-svn: 279897
|
|
|
|
| |
llvm-svn: 279896
|
|
|
|
| |
llvm-svn: 279894
|
|
|
|
| |
llvm-svn: 279884
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
easier to scan a set of options with a relatively large number of positional
arguments. This commit standardizes their formatting throughout LLDB and
applies surrounding directives to exempt them from being formatted by
clang-format.
These kinds of exemptions should be rare cases that benefit significantly
from alternative formatting. They also imply a long-term obligation to
maintain their format since the automated tools will not do so.
llvm-svn: 279882
|
|
|
|
|
|
|
|
|
| |
Reports an error instead. We can fix this later to make persistent variables
work, but right now we hit an LLVM assertion if we get this wrong.
<rdar://problem/27770298>
llvm-svn: 279850
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Oleksiy is no longer active in LLDB, I'd like to formally assume ownership of the linux and
android parts.
Reviewers: ovyalov, clayborg
Subscribers: tberghammer, danalbert, lldb-commits
Differential Revision: https://reviews.llvm.org/D23877
llvm-svn: 279812
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously the builting demangler was on for platforms that explicitly set a flag by modifying
Mangled.cpp (windows, freebsd). The Xcode build always used builtin demangler by passing a
compiler flag. This adds a cmake flag (defaulting to ON) to configure the demangling library used
at build time. The flag is only available on non-windows platforms as there the system demangler
is not present (in the form we're trying to use it, at least).
The impact of this change is:
- linux: switches to the builtin demangler
- freebsd, windows: NFC (I hope)
- netbsd: switches to the builtin demangler
- osx cmake build: switches to the builtin demangler (matching the XCode build)
The main motivation for this is the cross-platform case, where it should bring more consistency
by removing the dependency on the host demangler (which can be completely unrelated to the debug
target).
Reviewers: zturner, emaste, krytarowski
Subscribers: emaste, clayborg, lldb-commits
Differential Revision: https://reviews.llvm.org/D23830
llvm-svn: 279808
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
them.
Clang on ARM64 was making the three Function methods with identical bodies have
one implementation that was shared. That threw off the count of breakpoints, since
we don't count as separate locations three functions with the same address.
I also cleaned up the test case while I was at it.
<rdar://problem/27001915>
llvm-svn: 279800
|
|
|
|
|
|
|
|
| |
doesn't yield results and one has to go across multiple languages to scan for types
Fixes rdar://22422313
llvm-svn: 279784
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a preparatory commit for D22914, where I'd like to replace this mutex by an R/W lock
(which is also not recursive). This required a couple of changes:
- The only caller of Read/WriteRegister, GDBRemoteRegisterContext class, was already acquiring
the mutex, so these functions do not need to. All functions which now do not take a lock, take
an lock argument instead, to remind the caller of this fact.
- GetThreadSuffixSupported() was being called from locked and unlocked contexts (including
contexts where the process was running, and the call would fail if it did not have the result
cached). I have split this into two functions, one which computes the thread suffix support and
caches it (this one always takes the lock), and another, which returns the cached value (and
never needs to take the lock). This feels quite natural as ProcessGdbRemote was already
pre-caching this value at the start.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23802
llvm-svn: 279725
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Moving a temporary object prevents copy elision, which is exactly
what clang points out by warning about this pattern.
The fix is simply removal of std::move applied to temporary objects.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23825
Author: Taras Tsugrii <ttsugrii@fb.com>
llvm-svn: 279724
|
|
|
|
|
|
|
|
|
|
|
| |
and we couldn't find a dyld binary on the debug system, override
that setting and read dyld out of memory - we need to put an
internal breakpoint on dyld to register binaries being loaded or
unloaded; the debugger won't work right without dyld symbols.
<rdar://problem/27857025>
llvm-svn: 279704
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PlatformRemoteAppleWatch, PlatformRemoteAppleTV and remove the
GetFileInSDKRoot method from those classes.
The rewrite uses the more modern FileSpec etc API to simplify,
and handles the case where an SDK Root is given to lldb with
the "/Symbols" directory name already appended. The new version
will try appending "/Symbols" and "/Symbols.Internal" to the
sdk root directories, and will also try appending nothing to
the sdk root directory in case it's handed such an sdkroot.
<rdar://problem/28000054>
llvm-svn: 279688
|
|
|
|
|
|
|
|
| |
The newer event-based tests I added neglected to do the
macOS 10.12 check in the setup. This caused earlier macOS
test suite runs to attempt to compile code that doesn't exist.
llvm-svn: 279672
|
|
|
|
|
|
| |
NFC
llvm-svn: 279627
|
|
|
|
|
|
| |
<rdar://problem/27857025>
llvm-svn: 279611
|
|
|
|
|
|
|
|
|
|
| |
When, for instance, "step-in" steps into a function that it doesn't want
to stop in (e.g. has no debug info) it will push a step-out plan to implement
the step out so it can then continue stepping. These step out's don't use
the result of the function stepped out of, so they shouldn't spend the time
to compute it.
llvm-svn: 279540
|
|
|
|
|
|
| |
Also, when appending path components, collapse multiple "/" into one at the join.
llvm-svn: 279533
|
|
|
|
|
|
| |
The function was attempting to write the reply to the log even if the reply was empty.
llvm-svn: 279513
|
|
|
|
|
|
|
| |
The test was attempting to backtrace a process after every state change event (including the
"running", and "restarted" ones), which is not a good idea.
llvm-svn: 279512
|
|
|
|
| |
llvm-svn: 279446
|
|
|
|
|
|
|
|
|
|
|
|
| |
The lldb-gtest target is for CI and runs the tests as
part of the build phase. It does not support debugging
the gtests from Xcode, though, due to the run happening
during the build phase.
This change adds a lldb-gtest-for-debugging target that
can be used to debug gtests.
llvm-svn: 279354
|
|
|
|
|
|
|
|
| |
two singleton (pairtons?) instances of __NSCFBoolean that represent true and false
This is useful because that knowledge will in turn allow no-code-running formatting of boolean NSNumbers; but that's a commit that will have to wait Monday..
llvm-svn: 279353
|
|
|
|
|
|
|
|
|
|
|
| |
schemes.
This test was using a condition that would compare a variable against the register that would hold
it. It was failing with clang on arm64 because clang put the variable on the stack.
This is not a supportable way to write tests.
llvm-svn: 279345
|
|
|
|
|
|
|
|
|
|
| |
expression evaluation.
OrcMCJITReplacement is a reimplementation of MCJIT using ORC components, and
provides an easy upgrade path to ORC for existing MCJIT clients. There should be
no functional changes resulting from this switch.
llvm-svn: 279327
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r279296. Including LLDBDependencies breaks the
netbsd lldb bot because it exposes LLDB_USED_LIBS, which causes
lldb_link_common_libs to run to completion in unintended sites, which
results in a malformed call to target_link_libraries.
http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd7/builds/5989
Thanks to Chris Bieneman for figuring this out!
llvm-svn: 279322
|
|
|
|
| |
llvm-svn: 279316
|
|
|
|
|
|
|
| |
declaring that it must be first. Failure to do so results in build failures
on macOS due to subtle header conflicts.
llvm-svn: 279315
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's pulling in all kinds of things it doesn't need (e.g, clang-tidy!).
Eliminating this dependency removes 1056 dependencies from the
'CommandObjectFrame.cpp.o' target and 454 dependencies from the 'lldb'
target. On my machine, this shaves 7 minutes off of a clean build of
lldb.
Thanks to Zachary Turner for pointing out some issues with an earlier
version of this patch!
Differential Revision: https://reviews.llvm.org/D22987
llvm-svn: 279296
|
|
|
|
|
|
|
| |
GetByteSize() of a DataBuffer returns a uint64_t (it probably shouldn't), which isn't implicitly
convertible to size_t.
llvm-svn: 279238
|
|
|
|
|
|
|
| |
The pexpect import should be make after the skip-if-not-darwin part
because pexpect is not available on Windows
llvm-svn: 279234
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
+ small refactor
Summary:
The tricky part here was that the exisiting implementation of WriteAllRegisters was expecting
hex-encoded data (as that was what the first implementation I replaced was using, but here we had
binary data to begin with. I thought the read/write register functions would be more useful if
they handled the hex-encoding themselves (all the other client functions provide the responses in
a more-or-less digested form). The read functions return a DataBuffer, so they can allocate as
much memory as they need to, while the write functions functions take an llvm::ArrayRef, as that
can be constructed from pretty much anything.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23659
llvm-svn: 279232
|
|
|
|
|
|
|
|
| |
Exclusions:
ModuleCacheTest: https://llvm.org/bugs/show_bug.cgi?id=29045
SymbolFilePDBTests: https://llvm.org/bugs/show_bug.cgi?id=29046
llvm-svn: 279208
|
|
|
|
|
|
|
| |
Needed to explicitly turn off RTTI (since lldb-core builds
with -fno-rtti) and specify -DGTEST_HAVE_RTTI=0.
llvm-svn: 279205
|
|
|
|
|
|
|
|
| |
This change adds the Process/gdb-remote gtests to the Xcode
build. It also adds a virtual method impl to the continuation
delegate that I added with the StructuredDataPlugin change.
llvm-svn: 279203
|
|
|
|
|
|
|
|
|
|
|
|
| |
Take 2, with missing cmake line fixed. Build tested on
Ubuntu 14.04 with clang-3.6.
See docs/structured_data/StructuredDataPlugins.md for details.
differential review: https://reviews.llvm.org/D22976
reviewers: clayborg, jingham
llvm-svn: 279202
|
|
|
|
|
|
| |
This reverts commit 1d885845d1451e7b232f53fba2e36be67aadabd8.
llvm-svn: 279200
|
|
|
|
|
|
|
|
|
| |
See docs/structured_data/StructuredDataPlugins.md for details.
differential review: https://reviews.llvm.org/D22976
reviewers: clayborg, jingham
llvm-svn: 279198
|
|
|
|
|
|
| |
<rdar://problem/27897056>
llvm-svn: 279098
|
|
|
|
|
|
|
| |
The function can simply call the non-NoLock version of the SendPacket function and let it do the
locking.
llvm-svn: 279070
|