Commit Graph

9 Commits

Author SHA1 Message Date
Pavel Labath a2e270fa70 unittests: Use yaml2obj as a library instead of an external process
Summary:
Recently, yaml2obj has been turned into a library. This means we can use
it from our unit tests directly, instead of shelling out to an external
process. This patch does just that.

Reviewers: JDevlieghere, aadsm, espindola, jdoerfert

Subscribers: emaste, mgorny, arichardson, MaskRay, jhenderson, abrachet, lldb-commits

Differential Revision: https://reviews.llvm.org/D65949

llvm-svn: 369374
2019-08-20 12:28:36 +00:00
Pavel Labath 84a6856928 SymbolVendor: Move Symtab construction into the SymbolFile
Summary:
Instead of having SymbolVendor coordinate Symtab construction between
Symbol and Object files, make the SymbolVendor function a passthrough,
and put all of the logic into the SymbolFile.

Reviewers: clayborg, JDevlieghere, jingham, espindola

Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits

Differential Revision: https://reviews.llvm.org/D65208

llvm-svn: 367086
2019-07-26 07:03:28 +00:00
Greg Clayton 8a7779209d Include inlined functions when figuring out a contiguous address range
Checking this in for Antonio Afonso:

This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code.

My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy.

The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function.

To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend.

To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine.

To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue.

I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing.


Differential Revision: https://reviews.llvm.org/D61292

llvm-svn: 360071
2019-05-06 20:01:21 +00:00
Adrian Prantl 0e4c482124 Pass ConstString by value (NFC)
My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.

ConstString has exactly one const char * data member, so passing a
ConstString by reference is not any more efficient than copying it by
value. In both cases a single pointer is passed. But passing it by
value makes it harder to accidentally return the address of a local
object.

(This fixes rdar://problem/48640859 for the Apple folks)

Differential Revision: https://reviews.llvm.org/D59030

llvm-svn: 355553
2019-03-06 21:22:25 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Jonas Devlieghere 8f3be7a32b [FileSystem] Move path resolution logic out of FileSpec
This patch removes the logic for resolving paths out of FileSpec and
updates call sites to rely on the FileSystem class instead.

Differential revision: https://reviews.llvm.org/D53915

llvm-svn: 345890
2018-11-01 21:05:36 +00:00
Jonas Devlieghere 46376966ea [FileSystem] Extend file system and have it use the VFS.
This patch extends the FileSystem class with a bunch of functions that
are currently implemented as methods of the FileSpec class. These
methods will be removed in future commits and replaced by calls to the
file system.

The new functions are operated in terms of the virtual file system which
was recently moved from clang into LLVM so it could be reused in lldb.
Because the VFS is stateful, we turned the FileSystem class into a
singleton.

Differential revision: https://reviews.llvm.org/D53532

llvm-svn: 345783
2018-10-31 21:49:27 +00:00
Stefan Granitz 149fede165 Unit test for Symtab::InitNameIndexes
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
2018-08-02 10:13:18 +00:00
Stefan Granitz 2f842d68df Use LLVM's new ItaniumPartialDemangler in LLDB
Summary:
Replace the existing combination of FastDemangle and the fallback to llvm::itaniumDemangle() with LLVM's new ItaniumPartialDemangler. It slightly reduces complexity and slightly improves performance, but doesn't introduce conceptual changes. This patch is preparing for more fundamental improvements on LLDB's demangling approach.

Reviewers: friss, jingham, erik.pilkington, labath, clayborg, mgorny, davide, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: teemperor, JDevlieghere, labath, clayborg, davide, lldb-commits, mgorny, erik.pilkington

Differential Revision: https://reviews.llvm.org/D49612

llvm-svn: 337931
2018-07-25 15:19:04 +00:00