This also fixes a bug where SymbolFileDWARF was returning the same
function multiple times - this can happen if both mangled and demangled
names match the regex. Other lookup lookup functions had code to handle
this case, but it was forgotten here.
llvm-svn: 334277
Summary:
This patch implements the non-regex variant of GetFunctions. To share
more code with the Apple implementation, I've extracted the common
filtering code from that class into a utility function on the DWARFIndex
base class.
The new implementation also searching the accelerator table multiple
times -- previously it could happen that the apple table would return
the same die more than once if one specified multiple search flags in
name_type_mask. This way, I separate table iteration from filtering, and
so we can be sure each die is inserted at most once.
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47881
llvm-svn: 334273
Summary:
The patch adds support of splitted functions (when MSVC is used with PGO) and function-level linking feature.
SymbolFilePDB::ParseCompileUnitLineTable function relies on fact that ranges of compiled source files in the binary are continuous and don't intersect each other. The function creates LineSequence for each file and inserts it into LineTable, and implementation of last one relies on continuity of the sequence. But it's not always true when function-level linking enabled, e.g. in added input test file test-pdb-function-level-linking.exe there is xstring's std__basic_string_char_std__char_traits_char__std__allocator_char_____max_size (.00454820) between test-pdb-function-level-linking.cpp's foo (.00454770) and main (.004548F0).
To fix the problem this patch renews the sequence on each address gap.
Reviewers: asmith, zturner
Reviewed By: asmith
Subscribers: aleksandr.urakov, labath, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47708
llvm-svn: 334260
This breaks the OpenFlags enumeration into two separate
enumerations: OpenFlags and CreationDisposition. The first
controls the behavior of the API depending on whether or not
the target file already exists, and is not a flags-based
enum. The second controls more flags-like values.
This yields a more easy to understand API, while also allowing
flags to be passed to the openForRead api, where most of the
values didn't make sense before. This also makes the apis more
testable as it becomes easy to enumerate all the configurations
which make sense, so I've added many new tests to exercise all
the different values.
llvm-svn: 334221
When loading kexts in PlatformDarwinKernel, we use the BundleID as the
filename to to create shared modules. In GetSharedModule we call
ExamineKextForMatchingUUID for any BundleID it finds that is a match, to
see if the UUID is also a match. Until now we were using
Host::ResolveExecutableInBundle which calls a CoreFoundation API to
obtain the executable. However, it's possible that the executable has a
variant suffix (e.g. foo_development) and these files were ignored.
This patch replaces that call with logic that looks for all the binaries
in the bundle. Because of the way ExamineKextForMatchingUUID works, it's
fine to try to load executables that are not valid and we can just
iterate over the list until we found a match.
Differential revision: https://reviews.llvm.org/D47539
llvm-svn: 334205
This implements just one of the GetTypes overloads. The other is not
testable from lldb-test so I'm leaving it unimplemented until I figure
out what to do with testing.
llvm-svn: 334190
Summary:
It possible that a single module has indexed and non-indexed compile
units. In this case, we can use the fast indexed lookup for the first
ones and fall back to the manual index for the others.
This patch implements this functionality by adding a units_to_avoid
argument to the ManualDWARFIndex constructor. Any units present in that
list will be ignored for the purposes of manual index. Individual
DebugNamesDWARFIndex then always consult both the manual fallback index
as well as the index in the .debug_names section.
Reviewers: JDevlieghere, clayborg
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47832
llvm-svn: 334185
Summary:
This patch adds the ability to lookup variables to the DWARF v5 index
class.
During review we discovered an inconsistency between how the existing
two indexes handle looking up qualified names of the variables:
- manual index would return a value if the input string exactly matched
the demangled name of some variable.
- apple index ignored the context and returned any variable with the
same base name.
So, this patch also rectifies that situation:
- it removes all context handling from the index classes. The
GetGlobalVariables functions now just take a base name. For manual
index, this meant we can stop putting demangled names into the
variable index (this matches the behavior for functions).
- context extraction is put into SymbolFileDWARF, so that it is common
to all indexes.
- additional filtering based on the context is also done in
SymbolFileDWARF. This is done via a simple substring search, which is
not ideal, but it matches what we are doing for functions (cf.
Module::LookupInfo::Prune).
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47781
llvm-svn: 334181
Summary:
This patch adds the skeleton for implementing the DWARF v5 name index
class. All of the methods are stubbed out and will be implemented in
subsequent patches. The interesting part of the patch is the addition of
a "ignore-file-indexes" setting to the dwarf plugin which enables a
user to force using manual indexing path in lldb (for example as a
debugging aid). I have also added a test that verifies that file indexes
are used by default.
Reviewers: JDevlieghere, clayborg, jingham
Subscribers: mgorny, mehdi_amini, aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47629
llvm-svn: 334088
Summary:
The patch adds support of splitted functions (when MSVC is used with PGO) and function-level linking feature.
SymbolFilePDB::ParseCompileUnitLineTable function relies on fact that ranges of compiled source files in the binary are continuous and don't intersect each other. The function creates LineSequence for each file and inserts it into LineTable, and implementation of last one relies on continuity of the sequence. But it's not always true when function-level linking enabled, e.g. in added input test file test-pdb-function-level-linking.exe there is xstring's std__basic_string_char_std__char_traits_char__std__allocator_char_____max_size (.00454820) between test-pdb-function-level-linking.cpp's foo (.00454770) and main (.004548F0).
To fix the problem this patch renews the sequence on each address gap.
Reviewers: asmith, zturner
Reviewed By: asmith
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47708
llvm-svn: 334030
Now that Apple index determines method-ness straight from the debug
info, we don't need to resolve the functions into SymbolContexts inside
the Index classes. This removes the need for callback arguments and
allows us to pull the common parts out of the two implementations of
these functions back into the SymbolFileDWARF class.
Reviewers: JDevlieghere, clayborg
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47147
llvm-svn: 334004
The warning started firing after r333923, which added new builtin
types (fixed point types) into clang.
This patch merely silences the warning to unblock our integrate, does
not aim to support the new types in lldb.
llvm-svn: 333999
If BuildAddressRangeTable called ExtractDIEsIfNeeded(false), then another
thread started processing data from m_die_array and then the first thread
called final ClearDIEs() the second thread would crash.
It is also required without multithreaded debugger using DW_TAG_partial_unit
for DWZ.
Differential revision: https://reviews.llvm.org/D40470
llvm-svn: 333987
Host depended on clang because HostInfo had a function to get
the directory where clang was installed. We move this over to
the clang expression parser plugin where it's more at home.
Differential Revision: https://reviews.llvm.org/D47384
llvm-svn: 333933
Summary:
When searching for methods only, we need to do extra work to make sure
the functions we get from the apple tables are indeed methods.
Previously we were resolving the DIE into a SymbolContext and then
checked whether the enclosing CompilerDeclContext is a
class (or struct, or union).
This patch changes that to operate on the debug info directly. This
should be:
- simpler
- faster
- more consistent with the ManualDWARFIndex (which does the same check,
only at indexing time).
What we lose this ways is for the language plugin to have a say in what
it considers to be a "class", but that's probably more flexibility than
we need (and if we really wanted to do that in the future, we could
implement a more direct way to consult the plugin about this).
This also fixes the find-method-local-struct test, which was failing
because we were not able to construct a CompilerDeclContext for a local
struct correctly.
As a drive-by, I rename the DWARFDIE's IsStructClassOrUnion method to
match the name on the CompilerDeclContext class.
Reviewers: clayborg, JDevlieghere
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D47470
llvm-svn: 333878
On Darwin, the binary's symbol table points to debug info in object
files -- potentially object files within a static library. Such a
library may have multiple entries with the same name, distinguished
only by timestamp.
The code was already _attempting_ to handle this case (see the code in
ObjectContainerBSDArchive::Archive::FindObject which disambiguates via
timestamp). But, unfortunately, while the timestamp was taken into
account on the _first_ lookup, the result was then cached in a map
keyed only off of the path.
Added the timestamp to the cache, and added a test case.
Differential Revision: https://reviews.llvm.org/D47660
llvm-svn: 333813
In r331719, I changed Module::FindTypes not to limit the amount
of types returned by the Symbol provider, because we want all
possible matches to be able to filter them. In one code path,
the filtering was applied to the TypeList without changing the
number of types that gets returned. This is turn could cause
consumers to access beyond the end of the TypeList.
This patch fixes this case and also adds an assertion to
TypeList::GetTypeAtIndex to catch those obvious programming
mistakes.
Triggering the condition in which we performed the incorrect
access was not easy. It happened a lot in mixed Swift/ObjectiveC
code, but I was able to trigger it in pure Objective C++ although
in a contrieved way.
rdar://problem/40254997
llvm-svn: 333786
Summary:
Occasionally, when launching a process in lldb (especially on windows, but not limited to), lldb will hang before the process is launched and it will never recover. This happens because the timing of the processing of the state changes can be slightly different. The state changes that are issued are:
1) SetPublicState(eStateLaunching)
2) SetPrivateState(eStateLaunching)
3) SetPublicState(eStateStopped)
4) SetPrivateState(eStateStopped)
What we expect to see is:
public state: launching -> launching -> stopped
private state: launching -> stopped
What we see is:
public state: launching -> stopped -> launching
private state: launching -> stopped
The second launching change to the public state is issued when WaitForProcessStopPrivate calls HandlePrivateEvent on the event which was created when the private state was set to launching. HandlePrivateEvent has logic to determine whether to broadcase the event and a launching event is *always* broadcast. At the same time, when the stopped event is processed by WaitForProcessStopPrivate next, the function exists and that event is never broadcast, so the public state remains as launching.
HandlePrivateEvent does two things: determine whether there's a next action as well as determine whether to broadcast the event that was processed. There's only ever a next action set if we are trying to attach to a process, but WaitForProcessStopPrivate is only ever called when we are launching a process or connecting remotely, so the first part of HandlePrivateEvent (handling the next action) is irrelevant for WaitForProcessStopPrivate. As far as broadcasting the event is concerned, since we are handling state changes that already occurred to the public state (and are now duplicated in the private state), I believe the broadcast step is unnecessary also (and in fact, it causes the hang).
This change removes the call to HandlePrivateEvent from inside WaitForProcessStopPrivate.
Incidentally, there was also a bug filed recently that is the same issue: https://bugs.llvm.org/show_bug.cgi?id=37496
Reviewers: asmith, labath, zturner, jingham
Reviewed By: zturner, jingham
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47609
llvm-svn: 333781
Summary:
The LLDB.framework generated when building with CMake + Ninja/Make is
completely missing the clang headers. Although the code to copy them exists, we
don't even generate them unless we're building LLDB standalone.
Reviewers: clayborg, labath, sas
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47612
llvm-svn: 333777
This prevents Malloc from allocating the same chunk of memory twice, as
a byproduct of an alignment adjustment which gave the client access to
unallocated memory.
Prior to this patch, the newly-added test failed with:
$ lldb-test ir-memory-map ... ir-memory-map-overlap1.test
...
Command: malloc(size=64, alignment=32)
Malloc: address = 0x1000cd080
Command: malloc(size=64, alignment=8)
Malloc: address = 0x1000cd0b0
Malloc error: overlapping allocation detected, previous allocation at [0x1000cd080, 0x1000cd0c0)
Differential Revision: https://reviews.llvm.org/D47551
llvm-svn: 333697
Fixes infinite recursion due to change in how FileSpec deals with
removing the last path component.
Fixes timout for TestMiniDumpNew.py
llvm-svn: 333666
Summary:
As discussed in https://bugs.llvm.org/show_bug.cgi?id=37317,
FindGlobalVariables does not properly handle the case where
append=false. As this doesn't seem to be used in the tree, this patch
removes the parameter entirely.
Reviewers: clayborg, jingham, labath
Reviewed By: clayborg
Subscribers: aprantl, lldb-commits, kubamracek, JDevlieghere
Differential Revision: https://reviews.llvm.org/D46885
Patch by Tom Tromey <ttromey@mozilla.com>.
llvm-svn: 333639
rL145086 introduced m_die_array.shrink_to_fit() implemented by
exact_size_die_array.swap, it was before LLVM became written in C++11.
Differential revision: https://reviews.llvm.org/D47492
llvm-svn: 333636
This teaches lldb-test how to launch a process, set up an IRMemoryMap,
and issue memory allocations in the target process through the map. This
makes it possible to test IRMemoryMap in a targeted way.
This has uncovered two bugs so far. The first bug is that Malloc
performs an adjustment on the pointer returned from AllocateMemory (for
alignment purposes) which ultimately allows overlapping memory regions
to be created. The second bug is that after most of the address space on
the host side is exhausted, Malloc may return the same address multiple
times. These bugs (and hopefully more!) can be uncovered and tested for
with targeted lldb-test commands.
At an even higher level, the motivation for addressing these bugs is
that they can lead to strange user-visible failures (e.g, variables
assume the wrong value during expression evaluation, or the debugger
crashes). See my third comment on this swift-lldb PR for an example:
https://github.com/apple/swift-lldb/pull/652
I hope lldb-test is the right place to add this testing harness. Setting
up a gtest-style unit test proved too cumbersome (you need to recreate
or mock way too much debugger state), as did writing end-to-end tests
(it's hard to write a test that actually hits a buggy path).
With lldb-test, it's easy to read/generate the test input and parse the
test output. I'll attach a simple "fuzz" tester which generates failing
test cases to the Phab review. Here's an example:
```
Command: malloc(size=1024, alignment=32)
Malloc: address = 0xca000
Command: malloc(size=64, alignment=16)
Malloc: address = 0xca400
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca440
Command: malloc(size=16, alignment=8)
Malloc: address = 0xca840
Command: malloc(size=2048, alignment=16)
Malloc: address = 0xcb000
Command: malloc(size=64, alignment=32)
Malloc: address = 0xca860
Command: malloc(size=1024, alignment=16)
Malloc: address = 0xca890
Malloc error: overlapping allocation detected, previous allocation at [0xca860, 0xca8a0)
```
{F6288839}
Differential Revision: https://reviews.llvm.org/D47508
llvm-svn: 333583
When reading DBGSourcePathRemapping from a dSYM, we remove the last two
path components to make the source lookup more general. However, when
dealing with a relative path that has less than 2 components, we ended
up with an invalid (empty) FileSpec.
This patch changes the behavior of removeLastPathComponent to remove the
last path component, if possible. It does this by checking whether a
parent path exists, and if so using that as the new path. We rely
entirely on LLVM's path implementation to do the heavy lifting.
We now also return a boolean which indicates whether the operator was
successful or not.
Differential revision: https://reviews.llvm.org/D47495
rdar://37791687
llvm-svn: 333540
Summary:
Generating LLDB.framework when building with CMake+Ninja will copy the
lldb-private headers because public_headers contains them, even though we try
to make sure they don't get copied by removing root_private_headers from
root_public_headers.
This patch also removes SystemInitializerFull.h from the LLDB.framework headers when building with CMake.
Reviewers: compnerd, sas, labath, beanz, zturner
Reviewed By: labath
Subscribers: clayborg, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D47278
llvm-svn: 333444
GetUnitDIEPtrOnly() needs to return pointer to the first DIE.
But the first element of m_die_array after ExtractDIEsIfNeeded(true)
may move in memory after later ExtractDIEsIfNeeded(false).
DWARFDebugInfoEntry::collection m_die_array is std::vector,
its data may move during its expansion.
Differential revision: https://reviews.llvm.org/D46810
llvm-svn: 333437
Summary:
This improves the process of cross-compiling from macOS to Linux
since these files aren't used / needed at all.
Reviewers: clayborg, labath
Subscribers: lldb-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D47420
llvm-svn: 333400
Summary:
We were treating subprograms and inlined subroutines differently when
building the index. The difference was in which indexes were individual
tags inserted (subprograms went to all indexes, where as inlined
subroutines only into the basename and full name indexes).
This seems like an error, because an inlined subroutine can still
represent an C++ or an ObjC method. I don't see anything in the
subprogram branch which should not apply to an inlined subroutine, so I
propose to just treat them identically. This makes searching for an
inlined method behave the same way as for the apple index.
I write an assembly-based test because I did not want to depend on
particular clang inlining behavior (and because I wanted to see how hard
would it be).
Reviewers: clayborg, JDevlieghere
Subscribers: eraman, lldb-commits
Differential Revision: https://reviews.llvm.org/D47368
llvm-svn: 333398
Summary:
FastDemangle gives us a C-string that we own (which is allocated in SymbolDemangler::GetDemangledCopy).
As we are not deleting the string, we leak memory whenever we call SubsPrimitiveParmItanium.
Reviewers: javed.absar
Subscribers: kristof.beyls, chrib, lldb-commits
Differential Revision: https://reviews.llvm.org/D47418
llvm-svn: 333353
Summary: When compiling with modules, these missing includes cause the build to fail (as the header can't be compiled into a module).
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D47412
llvm-svn: 333345
Summary: This resolves unnecessary the header dependency from
Core to DataFormatters. Patch is necessary for the introduction of
C++ modules to the LLDB build system.
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D47409
llvm-svn: 333342
Summary:
It seems to me that files in include/lldb/API/ are headers that should
be exposed to liblldb users. Because SystemInitializerFull.h exposes details of
lldb_private, I think having it there is not the right thing to do. Since it's
only included from files in source/API, we should move it there and treat it as
private.
Reviewers: labath, clayborg
Reviewed By: labath, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D47342
llvm-svn: 333304
Pavel Labath