Summary:
.rela.debug_info relocations are being done via
ObjectFileELF::ApplyRelocations for aarch64. Currently, the switch case
that iterates over the relocation type is only implemented for a few
different types and `assert(false)`es over the rest.
Implement the relocation for R_AARCH64_ABS32 in ApplyRelocations
Reviewers: sas, xiaobai, javed.absar, espindola
Reviewed By: sas
Subscribers: emaste, arichardson, kristof.beyls
Differential Revision: https://reviews.llvm.org/D50369
Change by Nathan Lanza <lanza@fb.com>
llvm-svn: 339974
These TODOs were for setting m_type in RegisterValue::SetValueFromString
in the case where reg_info's encoding was eEncodingUint or
eEncodingSint. m_type is set by SetUInt{8,16,32,64.128} during the
SetUInt call.
llvm-svn: 339959
The single-process test runner is invoked in a number of different
scenarios, including when multiple test dirs are specified or (afaict)
when lit is used to drive the test suite.
Unfortunately the --test-subdir option did not work with the single
process test runner, breaking an important use case (using lit to run
swift-lldb Linux tests):
Failure URL: https://ci.swift.org/job/swift-PR-Linux/6841
We won't be able to run lldb tests within swift PR testing without
filtering down the set of tests.
This change makes --test-subdir work with the single-process runner.
llvm-svn: 339929
Include PosixAPI.h to get a PATH_MAX definition and replace CreateEvent
with CreateEventObject to avoid conflicts with the windows.h definition
of CreateEvent to CreateEventW.
llvm-svn: 339920
This patch adds a new lldb-vscode tool that speaks the Microsoft Visual Studio Code debug adaptor protocol. It has full unit tests that test all packets.
This tool can be easily packaged up into a native extension and used with Visual Studio Code, and it can also be used by Nuclide
Differential Revision: https://reviews.llvm.org/D50365
llvm-svn: 339911
when we have only an in-memory copy of the binary.
Also added a test for the generation of these symbols in the
in-memory and regular cases.
<rdar://problem/43160401>
llvm-svn: 339833
Patch by Shafik Yaghmour!
This reapplies an earlier version after addressing some post-commit feedback.
Differential Revision: https://reviews.llvm.org/D49271
llvm-svn: 339828
Summary:
CompletionTest.DirCompletionAbsolute had a random failure on a CI node
(in the failure, the completion count was 0, while we expected it to be 1),
but there seems no good reason for it to fail. The sanitizers don't complain
about the test when it's run, so I think we don't have some uninitialized
memory that we access here.
My best bet is that the unique directory selection randomly failed on the CI
node because maybe the FS there doesn't actually guarantee the atomic fopen
assumptions we make in the LLVM code (or some other funny race condition).
In this case a different test run could get the same directory and clean its contents
which would lead to 0 results.
The other possible explanation is that someone changed the CI configuration
on the node and changed the working dir to something very long, which would
make our PATH_MAX test fail (which also leads to 0 results), but I think that case
is unlikely.
This patch is just a stab in the dark that (hopefully) fixes this random failure by
giving each test a (more) unique working directory by appending the unique
test name to the temp-dir prefix. Also adds one more ASSERT_NO_ERROR to
one of our chdir calls just in case that is the reason for failing.
The good thing is that this refactor gets rid of most of the static variables
and files that we previously had as shared state between the different tests.
Potentially fixes rdar://problem/43150260
Reviewers: aprantl
Reviewed By: aprantl
Subscribers: jfb, lldb-commits
Differential Revision: https://reviews.llvm.org/D50722
llvm-svn: 339715
Summary:
This removes the manual byte counting mechanism from the syntax highlighting
code. This is no longer necessary as the Stream class now has built-in support for
automatically counting the bytes that were written to it so far.
The advantage of automatic byte counting via Stream is that it is less error-prone
than the manual version and we need to write less boilerplate code.
Reviewers: labath
Reviewed By: labath
Subscribers: labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D50676
llvm-svn: 339695
Summary:
This issue came up because it caused problems in our unit tests. The StringPool did connect counterparts only once and silently ignored the values passed in subsequent calls.
The simplest solution for the unit tests would be silent overwrite. In practice, however, it seems useful to assert that we never overwrite a different mangled counterpart.
If we ever have mangled counterparts for other languages than C++, this makes it more likely to notice collisions.
I added an assertion that allows the following cases:
* inserting a new value
* overwriting the empty string
* overwriting with an identical value
I fixed the unit tests, which used "random" strings and thus produced collisions.
It would be even better if there was a way to reset or isolate the StringPool, but that's a different story.
Reviewers: jingham, friss, labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D50536
llvm-svn: 339669
Summary:
In this patch I've tried to combine the best ideas from D49368 and D49410,
so it implements following:
- Completion of UDTs from a PDB with a filling of a layout info;
- Pointers to members;
- Fixes the bug relating to a virtual base offset reading from `vbtable`.
The offset was treated as an unsigned, but it can be a negative sometimes.
- Support of MSInheritance attribute
Reviewers: asmith, zturner, rnk, labath, clayborg, lldb-commits
Reviewed By: zturner
Subscribers: aleksandr.urakov, stella.stamenova, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D49980
llvm-svn: 339649
Summary:
We can optimize and refactor some of the classes in RangeMap.h, but first
we should have some tests for all the data structures in there. This adds a first
batch of tests for the Range class itself.
There are some unexpected results happening when mixing invalid and valid ranges, so
I added some FIXME's for that in the tests.
Reviewers: vsk
Reviewed By: vsk
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50620
llvm-svn: 339611
Summary:
Removing FastDemangle will greatly reduce maintenance efforts. This patch replaces the last point of use in LLDB. Semantics should be kept intact.
Once this is agreed upon, we can:
* Remove the FastDemangle sources
* Add more features e.g. substitutions in template parameters, considering all variations, etc.
Depends on LLVM patch https://reviews.llvm.org/D50586
Reviewers: erik.pilkington, friss, jingham, JDevlieghere
Subscribers: kristof.beyls, chrib, lldb-commits
Differential Revision: https://reviews.llvm.org/D50587
llvm-svn: 339583
Summary:
Instead of iterating over our vector of functions, we might as well use a map here to
directly get the function we need.
Thanks to Vedant for pointing this out.
Reviewers: vsk
Reviewed By: vsk
Subscribers: mgrang, lldb-commits
Differential Revision: https://reviews.llvm.org/D50225
llvm-svn: 339504
That comment was copied from the
CombineConsecutiveEntriesWithEqualData() implementation below,
and doesn't actually describe what's happening in the current
function.
llvm-svn: 339473
Summary:
Instead of just printing the current "False is not True, ..." message when we
fail to run a certain command, this patch also adds the actual command output or
error output that we received to the assertion message.
Reviewers: davide
Reviewed By: davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D50492
llvm-svn: 339351
This test relies on communicating with debugserver via an unnamed (pre-opened)
pipe, but macOS's version of debugserver doesn't seem to support that mode of
operation. So disable the test for now.
llvm-svn: 339343
Summary: It was not immediately clear to me whether or not non-null-terminated StringRef's are supported in ConstString and/or the counterpart mechanism. From this test it seems to be fine. Maybe useful to keep?
Reviewers: labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D50334
llvm-svn: 339292
Summary:
I set up a new review, because not all the code I touched was marked as a change in old one anymore.
In preparation for this review, there were two earlier ones:
* https://reviews.llvm.org/D49612 introduced the ItaniumPartialDemangler to LLDB demangling without conceptual changes
* https://reviews.llvm.org/D49909 added a unit test that covers all relevant code paths in the InitNameIndexes() function
Primary goals for this patch are:
(1) Use ItaniumPartialDemangler's rich mangling info for building LLDB's name index.
(2) Provide a uniform interface.
(3) Improve indexing performance.
The central implementation in this patch is our new function for explicit demangling:
```
const RichManglingInfo *
Mangled::DemangleWithRichManglingInfo(RichManglingContext &, SkipMangledNameFn *)
```
It takes a context object and a filter function and provides read-only access to the rich mangling info on success, or otherwise returns null. The two new classes are:
* `RichManglingInfo` offers a uniform interface to query symbol properties like `getFunctionDeclContextName()` or `isCtorOrDtor()` that are forwarded to the respective provider internally (`llvm::ItaniumPartialDemangler` or `lldb_private::CPlusPlusLanguage::MethodName`).
* `RichManglingContext` works a bit like `LLVMContext`, it the actual `RichManglingInfo` returned from `DemangleWithRichManglingInfo()` and handles lifetime and configuration. It is likely stack-allocated and can be reused for multiple queries during batch processing.
The idea here is that `DemangleWithRichManglingInfo()` acts like a gate keeper. It only provides access to `RichManglingInfo` on success, which in turn avoids the need to handle a `NoInfo` state in every single one of its getters. Having it stored within the context, avoids extra heap allocations and aids (3). As instantiations of the IPD the are considered expensive, the context is the ideal place to store it too. An efficient filtering function `SkipMangledNameFn` is another piece in the performance puzzle and it helps to mimic the original behavior of `InitNameIndexes`.
Future potential:
* `DemangleWithRichManglingInfo()` is thread-safe, IFF using different contexts in different threads. This may be exploited in the future. (It's another thing that it has in common with `LLVMContext`.)
* The old implementation only parsed and indexed Itanium mangled names. The new `RichManglingInfo` can be extended for various mangling schemes and languages.
One problem with the implementation of RichManglingInfo is the inaccessibility of class `CPlusPlusLanguage::MethodName` (defined in source/Plugins/Language/..), from within any header in the Core components of LLDB. The rather hacky solution is to store a type erased reference and cast it to the correct type on access in the cpp - see `RichManglingInfo::get<ParserT>()`. At the moment there seems to be no better way to do it. IMHO `CPlusPlusLanguage::MethodName` should be a top-level class in order to enable forward delcarations (but that is a rather big change I guess).
First simple profiling shows a good speedup. `target create clang` now takes 0.64s on average. Before the change I observed runtimes between 0.76s an 1.01s. This is still no bulletproof data (I only ran it on one machine!), but it's a promising indicator I think.
Reviewers: labath, jingham, JDevlieghere, erik.pilkington
Subscribers: zturner, clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50071
llvm-svn: 339291
Profiling data show that Allocation::operator= is hot (see the data
attached to the Phab review).
Reorder a few fields within Allocation to avoid implicit structure
padding and shrink the structure. This should make copies a bit cheaper.
Also, given that an Allocation contains a std::vector (by way of
DataBufferHeap), it's preferable to make it move-only instead of
permitting expensive copies. As an added benefit this allows us to have
a single Allocation constructor instead of two.
Differential Revision: https://reviews.llvm.org/D50271
llvm-svn: 339290
clang doesn't use line number 0 (to mean artifically generated code) very often, but swift does it
quite often. We were rejecting all by line breakpoints in functions that started at line 0. But that's
a special marker so we can just not do this test in that case.
llvm-svn: 339182
Double quotes are always correct in paths on windows while single quotes only work sometimes. By swapping the order of the quotes in the subsitution we guarantee that the quotes will be correct on Windows. Both sets work correctly on Linux in the test environment.
llvm-svn: 339180
Now target-select uses SB API instead of HandleCommand.
This patch has been reviewed along with the r339175.
Differential Revision: https://reviews.llvm.org/D49739
llvm-svn: 339178
Summary:
The new API appends an image search path to the
target's path mapping list.
Reviewers: aprantl, clayborg, labath
Reviewed By: aprantl
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D49739
llvm-svn: 339175
This change improves the logging for the lldb.module category to note a few interesting cases:
1. Local object file found, but specs not matching
2. Local object file not found, using a placeholder module
The handling and logging for the cases wehre we fail to load compressed dwarf
symbols is also improved.
Differential Revision: https://reviews.llvm.org/D50274
llvm-svn: 339161
Summary: Now this function uses SB API instead of HandleCommand.
Reviewers: aprantl, clayborg, labath
Reviewed By: aprantl
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D49632
llvm-svn: 339160
Summary:
There were previously no instructions for building LLDB on Mac OS X
with CMake. It's sufficiently close to building on Linux/FreeBSD/NetBSD that a
well-motivated developer could figure out the steps themselves. However, having
an explicit guide is better and can provide Mac OS X specific configurations
(e.g. LLDB_BUILD_FRAMEWORK).
Reviewers: labath, clayborg
Subscribers: emaste, krytarowski
Differential Revision: https://reviews.llvm.org/D50362
llvm-svn: 339155
These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall code layering (although it still does not break any particular
dependency completely).
The XCode project will need to be updated after this change.
Differential Revision: https://reviews.llvm.org/D49740
llvm-svn: 339127
Summary:
The issue with the python path is that the path to python on Windows can contain spaces. To make the tests always work, the path to python needs to be surrounded by quotes.
This is a companion change to: https://reviews.llvm.org/D50206
Reviewers: asmith, zturner
Differential Revision: https://reviews.llvm.org/D50280
llvm-svn: 339076
Summary:
.rela.debug_info relocations are being done via
ObjectFileELF::ApplyRelocations for aarch64. Currently, the switch case
that iterates over the relocation type is only implemented for a few
different types and `assert(false)`es over the rest.
Implement the relocation for R_AARCH64_ABS32 in ApplyRelocations
Reviewers: sas, xiaobai, peter.smith, clayborg, javed.absar, espindola
Differential Revision: https://reviews.llvm.org/D49407
Change by Nathan Lanza <lanza@fb.com>
llvm-svn: 339068
In the lldb-bench/arithmetic benchmark, 1.7% of the total running time
is spent zero-initializing a std::vector that has already been zeroed.
llvm-svn: 339051
In this patch I add support for ARM and ARM64 break pad files. There are two flavors of ARM: Apple where FP is R7, and non Apple where FP is R11. Added minimal tests that load up ARM64 and the two flavors or ARM core files with a single thread and known register values in each register. Each register is checked for the exact value.
This is a fixed version of: https://reviews.llvm.org/D49750
The changes from D49750 are:
Don't init the m_arch in the Initialize call as a system info isn't required. This keeps the thread list, module list and other tests from failing
Added -Wextended-offsetof to Xcode project so we catch use extended usages of offsetof before submission
Fixed any extended offset of warnings
Differential Revision: https://reviews.llvm.org/D50336
llvm-svn: 339032
Summary: `IsEmpty()` and `operator bool() == false` have equal semantics. Usage in Mangled::GetDemangledName() was incorrect. What it actually wants is a check for null-string. Split this off of D50071 and added a test to clarify usage.
Reviewers: labath, jingham
Subscribers: erik.pilkington, lldb-commits
Differential Revision: https://reviews.llvm.org/D50327
llvm-svn: 339014
Summary:
We already have the same check directly before, so this code can never be
reached (as seen in the test coverage).
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D50317
llvm-svn: 338976
I noticed a suspicious failure:
[ RUN ] VMRange.CollectionContains
llvm/src/tools/lldb/unittests/Utility/VMRangeTest.cpp:146: Failure
Value of: VMRange::ContainsRange(collection, VMRange(0x100, 0x104))
Actual: false
Expected: true
Looking at the code, it is a very real bug:
class RangeInRangeUnaryPredicate {
public:
RangeInRangeUnaryPredicate(VMRange range) : _range(range) {} // note that _range binds to a temporary!
bool operator()(const VMRange &range) const {
return range.Contains(_range);
}
const VMRange &_range;
};
This change fixes the bug.
Differential Revision: https://reviews.llvm.org/D50290
llvm-svn: 338949
Summary:
pudb and pdb interfere with the behavior of the inspect module. calling
`inspect.getfile(inspect.currentframe())` returns a different result
depending on whether or not you're in a debugger. Calling
`os.path.abspath` on the result of `inspect.getfile(...)` normalizes the
result between the two environments.
Patch by Nathan Lanza <lanza@fb.com>
Differential Revision: https://reviews.llvm.org/D49620
llvm-svn: 338923
Summary:
This wrapper will allow us in the future to reuse LLVM methods from within the
Stream class.
Currently no test as this is intended to be an internal class that shouldn't have any
NFC. The test for this change will be the follow up patch that migrates LLDB's
LEB128 implementation to the one from LLVM.
This change also adds custom move/assignment methods to Stream, as LLVM
raw_ostream doesn't support these. As our internal stream has anyway no state,
we can just keep the same stream object around.
Reviewers: davide, labath
Reviewed By: labath
Subscribers: xiaobai, labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D50161
llvm-svn: 338901
This reverts commit r338734 (and subsequent fixups in r338772 and
r338746), because it breaks some minidump unit tests and introduces a
lot of compiler warnings.
llvm-svn: 338828
Summary:
1) Several tests that are flakey on windows fail the run even if they are marked as expected to be flakey. This is because they fail frequently enough that even a retry won't help
2) Skip several tests on Windows that will occasionally hang rather than failing or exiting. This is causing the entire test suite to hang
Reviewers: asmith, labath, zturner
Reviewed By: zturner
Differential Revision: https://reviews.llvm.org/D50198
llvm-svn: 338769
In this patch I add support for ARM and ARM64 break pad files. There are two flavors of ARM: Apple where FP is R7, and non Apple where FP is R11. Added minimal tests that load up ARM64 and the two flavors or ARM core files with a single thread and known register values in each register. Each register is checked for the exact value.
Differential Revision: https://reviews.llvm.org/D49750
llvm-svn: 338734
Summary:
This patch allows LLDB's Stream class to count the bytes it has written to so far.
There are two major motivations for this patch:
The first one is that this will allow us to get rid of all the handwritten byte counting code
we have in LLDB so far. Examples for this are pretty much all functions in LLDB that
take a Stream to write to and return a size_t, which usually represents the bytes written.
By moving to this centralized byte counting mechanism, we hopefully can avoid some
tricky errors that happen when some code forgets to count the written bytes while
writing something to a stream.
The second motivation is that this is needed for the migration away from LLDB's `Stream`
and towards LLVM's `raw_ostream`. My current plan is to start offering a fake raw_ostream
class that just forwards to a LLDB Stream.
However, for this raw_ostream wrapper we need to fulfill the raw_ostream interface with
LLDB's Stream, which currently lacks the ability to count the bytes written so far (which
raw_ostream exposes by it's `tell()` method). By adding this functionality it is trivial to start
rolling out our raw_ostream wrapper (and then eventually completely move to raw_ostream).
Also, once this fake raw_ostream is available, we can start replacing our own code writing
to LLDB's Stream by LLVM code writing to raw_ostream. The best example for this is the
LEB128 encoding we currently ship, which can be replaced with by LLVM's version which
accepts an raw_ostream.
From the point of view of the pure source changes this test does, we essentially just renamed
the Write implementation in Stream to `WriteImpl` while the `Write` method everyone is using
to write its raw bytes is now just forwarding and counting the written bytes.
Reviewers: labath, davide
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D50159
llvm-svn: 338733
Summary: In order to exploit the potential of LLVM's new ItaniumPartialDemangler for indexing in LLDB, we expect conceptual changes in the implementation of the InitNameIndexes function. Here is a unit test that aims at covering all relevant code paths in that function.
Reviewers: labath, jingham, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: friss, teemperor, davide, clayborg, erik.pilkington, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D49909
llvm-svn: 338695
Summary:
This patch adds syntax highlighting support to LLDB. When enabled (and lldb is allowed
to use colors), printed source code is annotated with the ANSI color escape sequences.
So far we have only one highlighter which is based on Clang and is responsible for all
languages that are supported by Clang. It essentially just runs the raw lexer over the input
and then surrounds the specific tokens with the configured escape sequences.
Reviewers: zturner, davide
Reviewed By: davide
Subscribers: labath, teemperor, llvm-commits, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D49334
llvm-svn: 338662
As Jim pointed out, we don't need to manually create a target
here because we already create a target implicitly in the very
next line (which means we just created a target and don't use it).
This patch just removes the line that creates the first unused target.
llvm-svn: 338657
Summary:
When I added the Stream unit test (r338488), the build bots failed due to an out-of-
bound reads when passing an empty string to the PutCStringAsRawHex8 method.
In r338491 I removed the test case to fix the bots.
This patch fixes this in PutCStringAsRawHex8 by always checking for the terminating
null character in the given string (instead of skipping it the first time). It also re-adds the
test case I removed.
Reviewers: vsk
Reviewed By: vsk
Subscribers: vsk, lldb-commits
Differential Revision: https://reviews.llvm.org/D50149
llvm-svn: 338637
Summary:
Previously, I thought that install-liblldb would fail because CMake had
a bug related to installing frameworks. In actuality, I misunderstood the
semantics of `add_custom_target`: the DEPENDS option refers to specific files,
not targets. Therefore `install-liblldb` should rely on the actual liblldb
getting generated rather than the target.
This means that the previous patch I committed (to stop relying on CMake's
framework support) is no longer needed and has been reverted. Using CMake's
framework support greatly simplifies the implementation.
`install-lldb-framework` (and the stripped variant) is as simple as
depending on `install-liblldb` because CMake knows that liblldb was built as a
framework and will install the whole framework for you. The stripped variant
will depend on the stripped variants of individual tools only to ensure they
actually are stripped as well.
Reviewers: labath, sas
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50038
llvm-svn: 338594
Clarify how StackFrameList works by documenting its methods. Also,
delete some dead code and insert some TODOs.
Differential Revision: https://reviews.llvm.org/D50087
llvm-svn: 338590
Splitting GetOnlyConcreteFramesUpTo will make it easier to implement
support for synthetic tail call frames in backtraces. This is just a
prep change, no functionality is affected.
llvm-svn: 338588
The suspicious behavior is obviously because this method reads
OOB memory, so I'll remove it for now and re-add the test alongside
the fix later.
llvm-svn: 338491
Summary:
This adds an initial small unit test for LLDB's Stream class, which should at least cover
most of the functions in the Stream class. StreamString is always in big endian
mode, so that's the only stream byte order path this test covers as of now. Also,
the binary mode still needs to be tested for all print methods.
Also adds some FIXMEs for wrong/strange result values of the Stream class that we hit
while testing those functions.
Reviewers: labath
Reviewed By: labath
Subscribers: probinson, labath, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50027
llvm-svn: 338488
against the OS rather than the environment. Also update other
uses of OS when we meant environment in the android local code.
NFC intended.
llvm-svn: 338460
Summary: No one is using this method, and it also doesn't really make a lot of sense to have it around.
Reviewers: davide
Reviewed By: davide
Subscribers: davide, lldb-commits
Differential Revision: https://reviews.llvm.org/D50026
llvm-svn: 338345
Summary:
We usually don't have trailing newlines in the short help strings. This just adds
unnecessary extra lines when printing the help text of these commands.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D50015
llvm-svn: 338311
Summary: Otherwise this assertion message is not very useful to whoever is reading the log.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D49947
llvm-svn: 338179
This reverts r338154. This change is actually unnecessary, as the CMake
bug I referred to was actually not a bug but a misunderstanding of
CMake.
Original Differential Revision: https://reviews.llvm.org/D49888
llvm-svn: 338178
Aleksandr Urakov