Commit Graph

1527 Commits

Author SHA1 Message Date
Raphael Isemann 423c2e98e4 [lldb] Fix crash in CxxModuleHandler when std module is empty
We currently don't handle the error in the Expected we get
when searching for an equal local DeclContext. Usually this can't
happen as this would require that we have a STL container and
we can find libc++'s std module, but when we load the module in
the expression parser the module doesn't even contain the 'std'
namespace. The only way I see to test this is by having a fake
'std' module that requires a special define to actually provide
its contents, while it will just be empty (that is, it doesn't
even contain the 'std' namespace) without that define. LLDB currently
doesn't know about that define in the expression parser, so it
will load the wrong 'empty' module which should trigger this error.

Also removed the 'auto' for that variable as the function name
doesn't make it obvious that this is an expected and not just
a optional/ptr (which is how this slipped in from the start).

llvm-svn: 374525
2019-10-11 08:42:22 +00:00
Adrian Prantl 939411c1aa Remove the is_mangled flag from Mangled and Symbol
Testing whether a name is mangled or not is extremely cheap and can be
done by looking at the first two characters. Mangled knows how to do
it. On the flip side, many call sites that currently pass in an
is_mangled determination do not know how to correctly do it (for
example, they leave out Swift mangling prefixes).

This patch removes this entry point and just forced Mangled to
determine the mangledness of a string itself.

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

llvm-svn: 374180
2019-10-09 16:22:14 +00:00
Frederic Riss b56e3a1723 Add test coverage to printing of enums and fix display of unsigned values
TestCPP11EnumTypes.py should have covered all our bases when it comes
to typed enums, but it missed the regression introduced in r374066.
The reason it didn't catch it is somewhat funny: the test was copied
over from another test that recompiled a source file with a different
base type every time, but neither the test source nor the python code
was adapted for testing enums. As a result, this test was just running
8 times the exact same checks on the exact same binary.

This commit fixes the coverage and addresses the issue revealed by
the new tests.

llvm-svn: 374108
2019-10-08 19:52:01 +00:00
Frederic Riss 5d415b706f Fix sign extension handling in DumpEnumValue
When an enumerator has an unsigned type and its high bit set, the
code introduced in r374067 would fail to match it due to a sign
extension snafu. This commit fixes this aspec of the code and should
fix the bots.

I think it's not a complete fix though, I'll add more test coverage
and additional tweaks in a follow-up commit.

llvm-svn: 374095
2019-10-08 17:59:02 +00:00
Adrian Prantl ea63775054 Replace regex match with rfind (NFCish)
This change is mostly performance-neutral since our regex engine is
fast, but it's IMHO slightly more readable.  Also, matching matching
parenthesis is not a great match for regular expressions.

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

llvm-svn: 374082
2019-10-08 16:29:39 +00:00
Frederic Riss 41ff39605e Add pretty printing of Clang "bitfield" enums
Summary:
Using enumerators as flags is standard practice. This patch adds
support to LLDB to display such enum values symbolically, eg:

(E) e1 = A | B

If enumerators don't cover the whole value, the remaining bits are
displayed as hexadecimal:

(E) e4 = A | 0x10

Detecting whether an enum is used as a bitfield or not is
complicated. This patch implements a heuristic that assumes that such
enumerators will either have only 1 bit set or will be a combination
of previous values.

This patch doesn't change the way we currently display enums which the
above heuristic would not consider as bitfields.

Reviewers: jingham, labath

Subscribers: lldb-commits

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

llvm-svn: 374067
2019-10-08 15:35:59 +00:00
Frederic Riss d6470fb01a Extract and simplify DumpEnumValue
llvm-svn: 374066
2019-10-08 15:35:58 +00:00
Alex Langford f4c7345b88 [Symbol] Remove unused method ClangASTContext::GetObjCClassName
llvm-svn: 373990
2019-10-07 23:43:33 +00:00
Michal Gorny 9735739be7 [lldb] [cmake] Support linking against clang-cpp dylib
Link against clang-cpp dylib rather than split libs when
CLANG_LINK_CLANG_DYLIB is enabled.

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

llvm-svn: 373734
2019-10-04 12:03:03 +00:00
Richard Smith 772e266fbf Properly handle instantiation-dependent array bounds.
We previously failed to treat an array with an instantiation-dependent
but not value-dependent bound as being an instantiation-dependent type.
We now track the array bound expression as part of a constant array type
if it's an instantiation-dependent expression.

llvm-svn: 373685
2019-10-04 01:25:59 +00:00
Raphael Isemann ecbfb851a0 [lldb][NFC] Remove ClangASTContext::Clear
We now only use this function directly after initialization. As Clear()
resets the ASTContext back to its initial state, this is just a no-op.
There are no other users for this and we no longer can set the ASTContext
after construction, so Clear has no useful purpose anymore. It's also
mostly copy-pasted from Finalize().

llvm-svn: 373460
2019-10-02 12:38:04 +00:00
Raphael Isemann 2eb963abff [lldb][NFC] Create the ASTContext in ClangASTContext exactly once.
Reason for this patch is the Ssame reason as for the previous patches:
Having a ClangASTContext and being able to switch the associated ASTContext isn't
a use case we have (or should have), so let's simplify all this code.
This way it becomes clearer in what order we initialize data structures.

The DWARFASTParserClangTests changes are necessary as the test is using
a ClangASTContext but relied on the fact that no called function ever calls
getASTContext() on our ClangASTContext (as that would create the ASTContext).
As we now always create the ASTContext the fact that we had an uninitialized
FileSystem made the test crash.

llvm-svn: 373457
2019-10-02 12:26:08 +00:00
Adrian Prantl bf9d84c014 Remove size_t return parameter from FindTypes
In r368345 I accidentally introduced a regression that would
over-report the number of matches found by FindTypes if the
DeclContext Filter was hit.

This patch simply removes the size_t return parameter altogether —
it's not that useful.

rdar://problem/55500457

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

llvm-svn: 373344
2019-10-01 15:40:41 +00:00
Raphael Isemann e4e305e5ee [lldb][NFC] Remove unused ClangASTContext::GetHasExternalStorage
This code isn't used nor tested.

llvm-svn: 373337
2019-10-01 13:25:25 +00:00
Raphael Isemann 1ce75045eb [lldb][NFC] Remove unused ClangASTContext functions for checking/removing the ExternalASTSource
llvm-svn: 373334
2019-10-01 13:05:57 +00:00
Raphael Isemann c73bfc98f8 [lldb][NFC] Disallow changing the ASTContext of an ClangASTContext after construction.
We have no use case in LLDB where we actually do want to change the ASTContext after
it the ClangASTContext has been constructed. All callers of setASTContext are just setting
the ASTContext directly after construction, so we might as well make this a Constructor
instead of supporting this tricky use case.

llvm-svn: 373330
2019-10-01 12:55:37 +00:00
Raphael Isemann d01b4a7862 [lldb][NFC] Modernize ClangASTContext constructor
Now using default initializers and StringRef.

Also formats the member list that we excluded from clang-format
at some point and still hangs around with the old LLDB code style.

llvm-svn: 373329
2019-10-01 12:28:14 +00:00
Vedant Kumar c03c2e886e [StackFrameList][DFS] Turn a few raw pointers into references, NFC
llvm-svn: 373267
2019-09-30 21:20:14 +00:00
Adrian Prantl d4d428ef92 Remove unused "append" parameter from FindTypes API
I noticed that SymbolFileDWARFDebugMap::FindTypes was implementing it
incorrectly (passing append=false in a for-loop to recursive calls to
FindTypes would yield only the very last set of results), but instead
of fixing it, removing it seemed like an even better option.

rdar://problem/54412692

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

llvm-svn: 373224
2019-09-30 16:42:28 +00:00
Pavel Labath 6f23a68a84 Use llvm for dumping DWARF expressions
Summary:
It uses the new ability of ABI plugins to vend llvm::MCRegisterInfo
structs (which is what is needed to turn dwarf register numbers into
strings).

Reviewers: JDevlieghere, aprantl, jasonmolenda

Subscribers: tatyana-krasnukha, lldb-commits

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

llvm-svn: 373208
2019-09-30 13:44:17 +00:00
Pavel Labath a8b284eeec Unwind: Add a stack scanning mechanism to support win32 unwinding
Summary:
Windows unwinding is weird. The unwind rules do not (always) describe
the precise layout of the stack, but rather expect the debugger to scan
the stack for something which looks like a plausible return address, and
the unwind based on that. The reason this works somewhat reliably is
because the the unwinder also has access to the frame sizes of the
functions on the stack. This allows it (in most cases) to skip function
pointers in local variables or function arguments, which could otherwise
be mistaken for return addresses.

Implementing this kind of unwind mechanism in lldb was a bit challenging
because we expect to be able to statically describe (in the UnwindPlan)
structure, the layout of the stack for any given instruction. Giving a
precise desription of this is not possible, because it requires
correlating information from two functions -- the pushed arguments to a
function are considered a part of the callers stack frame, and their
size needs to be considered when unwinding the caller, but they are only
present in the unwind entry of the callee. The callee may end up being
in a completely different module, or it may not even be possible to
determine it statically (indirect calls).

This patch implements this functionality by introducing a couple of new
APIs:
SymbolFile::GetParameterStackSize - return the amount of stack space
  taken up by parameters of this function.
SymbolFile::GetOwnFrameSize - the size of this function's frame. This
  excludes the parameters, but includes stuff like local variables and
  spilled registers.

These functions are then used by the unwinder to compute the estimated
location of the return address. This address is not always exact,
because the stack may contain some additional values -- for instance, if
we're getting ready to call a function then the stack will also contain
partially set up arguments, but we will not know their size because we
haven't called the function yet. For this reason the unwinder will crawl
up the stack from the return address position, and look for something
that looks like a possible return address. Currently, we assume that
something is a valid return address if it ends up pointing to an
executable section.

All of this logic kicks in when the UnwindPlan sets the value of CFA as
"isHeuristicallyDetected", which is also the final new API here. Right
now, only SymbolFileBreakpad implements these APIs, but in the future
SymbolFilePDB will use them too.

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

llvm-svn: 373072
2019-09-27 12:10:06 +00:00
Vedant Kumar f6bc251274 [Mangle] Add flag to asm labels to disable '\01' prefixing
LLDB synthesizes decls using asm labels. These decls cannot have a mangle
different than the one specified in the label name. I.e., the '\01' prefix
should not be added.

Fixes an expression evaluation failure in lldb's TestVirtual.py on iOS.

rdar://45827323

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

llvm-svn: 372903
2019-09-25 18:00:31 +00:00
Raphael Isemann 9379d19ff8 [lldb] Decouple importing the std C++ module from the way the program is compiled
Summary:
At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program
and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to
cause a few problems or inconveniences:

* It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible
for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default
(and we can't just close all the associated bug reports).
* Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux).
* We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS).

This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit.
If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module
configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information
than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the
`Darwin` module are their own external type module with their own files).

The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths
based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some
test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism),
but for now it works and makes the feature usable.

Reviewers: aprantl, shafik, jdoerfert

Reviewed By: aprantl

Subscribers: mgorny, abidh, JDevlieghere, lldb-commits

Tags: #c_modules_in_lldb, #lldb

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

llvm-svn: 372716
2019-09-24 10:08:18 +00:00
Raphael Isemann 15695cd69c [lldb] Fix LLDB build after r372538
llvm-svn: 372548
2019-09-23 06:59:35 +00:00
Adrian Prantl 330014843c Doxygenify comments.
llvm-svn: 372411
2019-09-20 17:15:57 +00:00
Raphael Isemann 6192ad2622 Move decl completion out of the ASTImporterDelegate and document it [NFC]
Summary:
The ASTImporterDelegate is currently responsible for both recording and also completing
types. This patch moves the actual completion and recording code outside the ASTImporterDelegate
to reduce the amount of responsibilities the ASTImporterDelegate has to fulfill.

As I anyway had to touch the code when moving I also documented and refactored most of it
(e.g. no more asserts that we call the deporting start/end function always as a pair).

Note that I had to make the ASTImporterDelegate and it's related functions public now so that
I can move out the functionality in another class (that doesn't need to be in the header).

Reviewers: shafik, aprantl, martong, a.sidorin

Reviewed By: martong

Subscribers: rnkovacs, lldb-commits

Tags: #lldb

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

llvm-svn: 372385
2019-09-20 12:52:55 +00:00
Richard Smith c624510f13 For PR17164: split -fno-lax-vector-conversion into three different
levels:

 -- none: no lax vector conversions [new GCC default]
 -- integer: only conversions between integer vectors [old GCC default]
 -- all: all conversions between same-size vectors [Clang default]

For now, Clang still defaults to "all" mode, but per my proposal on
cfe-dev (2019-04-10) the default will be changed to "integer" as soon as
that doesn't break lots of testcases. (Eventually I'd like to change the
default to "none" to match GCC and general sanity.)

Following GCC's behavior, the driver flag -flax-vector-conversions is
translated to -flax-vector-conversions=integer.

This reinstates r371805, reverted in r371813, with an additional fix for
lldb.

llvm-svn: 371817
2019-09-13 06:02:15 +00:00
Vedant Kumar 21d417dc18 [DWARF] Evaluate DW_OP_entry_value
Add support for evaluating DW_OP_entry_value. This involves parsing
DW_TAG_call_site_parameter and wiring the information through to the expression
evaluator.

rdar://54496008

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

llvm-svn: 371668
2019-09-11 21:23:45 +00:00
Vedant Kumar ff02109ad4 [Function] Factor out GetCallEdgeForReturnAddress, NFC
Finding the call edge in a function which corresponds to a particular
return address is a generic/useful operation.

llvm-svn: 371543
2019-09-10 18:36:50 +00:00
Jonas Devlieghere e0ea8d87eb [Utility] Replace `lldb_private::CleanUp` by `llvm::scope_exit`
This removes the CleanUp class and replaces its usages with llvm's
ScopeExit, which has similar semantics.

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

llvm-svn: 371474
2019-09-10 00:20:50 +00:00
Alex Langford 9e86561878 [Symbol] Give ClangASTContext a PersistentExpressionState instead of a ClangPersistentVariables
ClangASTContext doesn't use m_persistent_variables in a way specific to
ClangPersistentVariables. Therefore, it should hold a unique pointer to
PersistentExpressionState instead of a ClangPersistentVariablesUP.
This also prevents you from pulling in a plugin header when including
ClangASTContext.h

Doing this exposed an implicit dependency in ObjCLanguage that was
corrected by including ClangModulesDeclVendor.h

llvm-svn: 371470
2019-09-09 23:11:43 +00:00
Alex Langford b482db6dfe [Core] Remove use of ClangASTContext in DumpDataExtractor
Summary:
DumpDataExtractor uses ClangASTContext in order to get the proper llvm
fltSemantics for the type it needs so that it can dump floats in a more
precise way. However, there's no reason that this behavior needs to be
specific ClangASTContext. Instead, I think it makes sense to ask
TypeSystems for the float semantics for a type of a given size.

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

llvm-svn: 371258
2019-09-06 21:05:21 +00:00
Jonas Devlieghere 4be6706eb6 [Disassembler] Simplify a few methods (NFC)
Use early returns to highlight preconditions and make the code easier to
follow.

llvm-svn: 370994
2019-09-04 22:38:20 +00:00
Raphael Isemann 2f323fc790 [lldb][NFC] Refactor and document ClangASTContext::IsOperator
Should make it clearer what actually is going on in there.

llvm-svn: 370201
2019-08-28 13:46:01 +00:00
Pavel Labath c7deb7f808 Postfix: move more code out of the PDB plugin
Summary:
Previously we moved the code which parses a single expression out of the PDB
plugin, because that was useful for DWARF expressions in breakpad. However, FPO
programs are used in breakpad files too (when unwinding on windows), so this
completes the job, and moves the rest of the FPO parser too.

Reviewers: amccarth, aleksandr.urakov

Subscribers: aprantl, markmentovai, rnk, lldb-commits

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

llvm-svn: 369894
2019-08-26 11:44:14 +00:00
Alex Langford cb68bd726d [Symbol] Decouple clang from DeclVendor
Summary:
This removes DeclVendor's dependency on clang (and ClangASTContext).
DeclVendor has no need to know about specific TypeSystems.

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

llvm-svn: 369735
2019-08-23 06:11:32 +00:00
Jonas Devlieghere 6c9dc12caa [LLDB] Address post-commit code review feedback.
This patch addresses Adrian McCarthy's code review feedback in
https://reviews.llvm.org/D66447

llvm-svn: 369731
2019-08-23 04:11:38 +00:00
Adrian Prantl aa97a89d83 Extend FindTypes with CompilerContext to allow filtering by language.
This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.

In multi-language projects it is extremely common to have, e.g., a
Clang type and a similarly-named rendition of that same type in
another language. When searching for a type It is much cheaper to pass
a set of supported languages to the SymbolFile than having it
materialize every result and then rejecting the materialized types
that have the wrong language.

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

<rdar://problem/54471165>

This reapplies r369690 with a previously missing constructor for LanguageSet.

llvm-svn: 369710
2019-08-22 21:45:58 +00:00
Adrian Prantl b041602e3f Revert Extend FindTypes with CompilerContext to allow filtering by language.
This reverts r369690 (git commit aa3a564efa)

llvm-svn: 369702
2019-08-22 20:41:16 +00:00
Adrian Prantl aa3a564efa Extend FindTypes with CompilerContext to allow filtering by language.
This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch.

In multi-language projects it is extremely common to have, e.g., a
Clang type and a similarly-named rendition of that same type in
another language. When searching for a type It is much cheaper to pass
a set of supported languages to the SymbolFile than having it
materialize every result and then rejecting the materialized types
that have the wrong language.

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

<rdar://problem/54471165>

llvm-svn: 369690
2019-08-22 19:24:55 +00:00
Raphael Isemann ae34ed2c0d [lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:

* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.

I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.

A few words why those things should be removed/replaced:

* The return values are really cryptic, partly redundant and rarely documented.
  They are also completely ignored by Xcode, so whatever information they contain will end up
  breaking Xcode's completion mechanism. They are also partly impossible to even implement
  as we assign negative values special meaning and our completion API sometimes returns size_t.

  Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
  in some untested code path to expand the history repeat character to the full command, but
  I haven't figured out why that doesn't work at the moment.
  Completion functions return -1 to 'insert the completion character', but that isn't implemented
  (even though we seem to activate this feature in LLDB sometimes).
  All positive values have to match the number of results. This is obviously just redundant information
  as the user can just look at the result list to get that information (which is what Xcode does).

* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
  reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
  that we calculate this to make the life of the API caller easier, but obviously forcing people to have
  1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
  0-based like Xcode has to do).

* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
  idea is that we let the top-level API know that we just provided a full completion. Interestingly we
  `WordComplete` is just a single bool that somehow represents all N completions. And we always
  provide full completions in LLDB, so in theory it should always be true.
  The only use it currently serves is providing redundant information about whether we have a single
  definitive completion or not (which we already know from the number of results we get).

This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.

For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).

I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Subscribers: arphaman, abidh, lldb-commits

Tags: #lldb

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

llvm-svn: 369624
2019-08-22 07:41:23 +00:00
Jonas Devlieghere c46d39b9e8 Add char8_t support (C++20)
This patch adds support for the char8_t type introduced in C++20
char8_t. The original patch was submitted by James Blachly  on the LLDB
mailing list [1]. I modified the patch a bit and added a test.

[1] http://lists.llvm.org/pipermail/lldb-dev/2019-August/015393.html

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

llvm-svn: 369582
2019-08-21 21:30:55 +00:00
Adrian Prantl 330ae19a1a Generalize FindTypes with CompilerContext to support fuzzy lookup
This patch generalizes the FindTypes with CompilerContext interface to
support looking up a type of unknown kind by name, as well as looking
up a type inside an unspecified submodule. These features are
motivated by the Swift branch, but are fully tested via unit tests and
lldb-test on llvm.org.  Specifically, this patch adds an AnyModule and
an AnyType CompilerContext kind.

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

rdar://problem/54471165

llvm-svn: 369555
2019-08-21 18:06:56 +00:00
Pavel Labath 65a376f091 Fix two compiler warnings
llvm-svn: 369522
2019-08-21 13:11:30 +00:00
Pavel Labath 9cb317968a Fix an unused variable warning in ClangASTContext.cpp
llvm-svn: 369503
2019-08-21 08:22:19 +00:00
Alex Langford 7719495e2c [Symbol] Remove unused clang headers from Type
llvm-svn: 369494
2019-08-21 04:56:23 +00:00
Alex Langford b2232a1af3 [Symbol] Move VerifyDecl to ClangASTContext
VerifyDecl is specific to clang and is only used in ClangASTContext.

llvm-svn: 369456
2019-08-20 22:06:13 +00:00
Alex Langford cb40f89c6e [Symbol][NFC] Remove references to clang in TypeMap
llvm-svn: 369436
2019-08-20 20:44:36 +00:00
Raphael Isemann 0684132107 [lldb][NFC] Use CompletionRequest in Variable::AutoComplete
llvm-svn: 369252
2019-08-19 11:49:43 +00:00
Jonas Devlieghere 3af3f1e8e2 [Utility] Reimplement RegularExpression on top of llvm::Regex
Originally I wanted to remove the RegularExpression class in Utility and
replace it with llvm::Regex. However, during that transition I noticed
that there are several places where need the regular expression string.
So instead I propose to keep the RegularExpression class and make it a
thin wrapper around llvm::Regex.

This patch also removes the workaround for empty regular expressions.
The result is that we are now (more or less) POSIX conformant.

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

llvm-svn: 369153
2019-08-16 21:25:36 +00:00
Shafik Yaghmour 62abe494fb Improve anonymous class heuristic in ClangASTContext::CreateRecordType
Summary:
Currently the heuristic used in ClangASTContext::CreateRecordType to identify an anonymous class is that there is that name is a nullptr or simply a null terminator. This heuristic is not accurate since it will also sweep up unnamed classes and lambdas. The improved heuristic relies on the requirement that an anonymous class must be contained within a class.

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

llvm-svn: 368937
2019-08-14 22:30:29 +00:00
Jonas Devlieghere a8f3ae7c9c [LLDB] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

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

llvm-svn: 368933
2019-08-14 22:19:23 +00:00
Jonas Devlieghere 235339357d [DWARF} Use LLVM's debug line parser in LLDB.
The line number table header was substantially revised in DWARF 5 and is
not fully supported by LLDB's current debug line implementation.

This patch replaces the LLDB debug line parser with its counterpart in
LLVM. This was possible because of the limited contact surface between
the code to parse the DWARF debug line section and the rest of LLDB.

We pay a small cost in terms of performance and memory usage. This is
something we plan to address in the near future.

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

llvm-svn: 368742
2019-08-13 19:51:51 +00:00
Alex Langford bddab07d4a [Symbol] Decouple clang from CompilerType
Summary:
Ideally CompilerType would have no knowledge of clang or any individual
TypeSystem. Decoupling clang is relatively straightforward.

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

llvm-svn: 368741
2019-08-13 19:40:36 +00:00
Alex Langford f4446f1775 [Symbol] Remove redundant include
llvm-svn: 368638
2019-08-13 00:25:49 +00:00
Davide Italiano 7f9bbe0599 [CompilerType] Pass an ExecutionContextScope to GetTypeBitAlign.
llvm-svn: 368620
2019-08-12 21:49:54 +00:00
Davide Italiano 36f13e4912 [Symbol] GetTypeBitAlign() should return None in case of failure.
Summary:
And not `zero`. This is the last API needed to be converted to
an Optional<T>.

Reviewers: xiaobai, compnerd

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 368614
2019-08-12 20:03:19 +00:00
Raphael Isemann 339b5d1ac2 [lldb][NFC] Fix warning about missing switch cases
These types were recently added in D62960 but it seems the patch didn't
consider LLDB which causes a bunch of compiler warnings about
missing enum values. It seems this feature isn't fully implemented yet,
so I don't think we can write any test for this. For now lets just add
the missing types to our usual list of unsupported types.

llvm-svn: 368424
2019-08-09 09:58:47 +00:00
Pavel Labath 0de33de813 Fix LLDB_CONFIGURATION_DEBUG builds for the GetSymbolVendor removal
fix one usage that is ifdefed-out in non-debug builds.

llvm-svn: 368279
2019-08-08 11:49:55 +00:00
Alex Langford 4cd04547f5 [Symbol] Remove commented out code from CompileUnit
llvm-svn: 368205
2019-08-07 20:51:21 +00:00
Raphael Isemann 44b8e5f4a6 [lldb][NFC] Remove commented out code in ClangASTContext::AddMethodToCXXRecordType
llvm-svn: 368150
2019-08-07 10:59:34 +00:00
Pavel Labath 465eae3669 SymbolVendor: Remove passthrough methods
After the recent refactorings the SymbolVendor passthrough no longer
serve any purpose. This patch removes those methods, and updates all
callsites to go to the symbol file directly -- in most cases that just
means calling GetSymbolFile()->foo() instead of
GetSymbolVendor()->foo().

llvm-svn: 368001
2019-08-06 09:12:42 +00:00
Pavel Labath 001ecbde11 SymbolVendorELF: Perform build-id lookup even without a debug link
Summary:
The debug link and build-id lookups are two independent ways one can
search for a separate symbol file. However, our implementation in
SymbolVendorELF was tying the two together and refusing to look up the
symbol file based on a build id if the file did not contain a debug
link.

This patch makes it possible to search for the symbol file with
just one of the two methods available. To demonstrate, I split the
build-id-case test into two, so that we test the search using both
methods.

Reviewers: jankratochvil, mgorny, clayborg, espindola, alexshap

Subscribers: emaste, arichardson, MaskRay, lldb-commits

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

llvm-svn: 367994
2019-08-06 08:18:39 +00:00
Pavel Labath a3bdcdf714 Fix line table resolution near the end of a section
Summary:
lld r367537 changed the way the linker organizes sections and segments.
This exposed an lldb bug and caused some tests to fail.

In all of the failing tests the root cause was the same -- when we were
trying to resolve the last address in the line_table section, we failed
because it pointed past the end of the section.

This patch changes the line table address resolution code to back up the
address by one for end-of-sequence entries. This ensures the address
still points inside a section/module even if the line table sequence
ends at the very end of a section.

It also reverts the linker flags which were added to the failing tests
to restore previous behavior.

Reviewers: clayborg, jingham

Subscribers: mgorny, MaskRay, lldb-commits

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

llvm-svn: 367983
2019-08-06 06:52:05 +00:00
Davide Italiano 78f05d3599 Revert "[CompilerType] Simplify the interface a bit more.."
There's actually a test downstream that fails with this.
I think we can still get rid of it, but I need to do some work
there first.

llvm-svn: 367963
2019-08-06 00:42:11 +00:00
Davide Italiano b31f60b9c2 [CompilerType] Simplify the interface a bit more..
Summary:
.. removing IsMeaninglessWithoutTypeResolution(). I'm fairly
confident this was introduced to support swift, where
static types [without dynamic counterpart] don't carry a lot
of value. Since then, the formatters and dynamic type resolution
has been rewritten, and we employ different solutions. This function
is unused here too, so let's get read of it.

<rdar://problem/36377967>

Reviewers: shafik, JDevlieghere, alex, compnerd, teemperor

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 367957
2019-08-06 00:01:52 +00:00
Davide Italiano d32d5db4da [CompilerType] Remove an unused function.
Summary:
This simplifies the interface, as I'm trying to understand how
we can upstream swift support.

<rdar://problem/36377967>

Reviewers: teemperor, JDevlieghere, xiaobai, compnerd, friss

Subscribers: lldb-commits

Tags: #lldb

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

llvm-svn: 367946
2019-08-05 23:18:00 +00:00
Rainer Orth 6ca1707b23 [lldb][clang] Reflect LangStandard.h move to clang/Basic
D65562 <https://reviews.llvm.org/D65562> moves LangStandard.h from clang/Frontend to clang/Basic.  This patch
adjusts the single file in lldb that uses it to match.

Tested on x86_64-pc-linux-gnu.

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

llvm-svn: 367865
2019-08-05 14:00:43 +00:00
Pavel Labath 5a7e1e978f Fix PDB tests after r367820
The commit changed Module dumping code to call SymbolFile::Dump
directly, which meant that we were no longer showing the plugin name in
the output (as that was done in the SymbolVendor).

This adds the plugin name printing code to the SymbolFile dump method,
and tweak the assertions in the PDB tests to match it correctly.

llvm-svn: 367835
2019-08-05 11:29:01 +00:00
Pavel Labath d5d47a3574 Remove SymbolVendor::GetSymtab
Summary:
This patch removes the GetSymtab method from the SymbolVendor, which is
a no-op as it's implementation just forwards to the relevant SymbolFile.
Instead it creates a Module::GetSymtab, which calls the SymbolFile
method directly.

All callers have been updated to use the Module method directly instead
of a two phase GetSymbolVendor->GetSymtab search, which leads to reduced
intentation in a lot of deeply nested code.

Reviewers: clayborg, JDevlieghere, jingham

Subscribers: lldb-commits

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

llvm-svn: 367820
2019-08-05 09:21:47 +00:00
Shafik Yaghmour fa5c340ea1 Fix ClangASTContext::CreateParameterDeclaration to not call addDecl
Summary:
The change https://reviews.llvm.org/D55575 modified ClangASTContext::CreateParameterDeclaration to call decl_ctx->addDecl(decl); this caused a regression since the existing code in DWARFASTParserClang::ParseChildParameters is called with the containing DeclContext. So when end up with cases where we are parsing a parameter for a member function and the parameter is added to the CXXRecordDecl as opposed to the CXXMethodDecl. This example is given in the regression test TestBreakpointInMemberFuncWNonPrimitiveParams.py which without this fix in a modules build leads to assert on setting a breakpoint in a member function with non primitive parameters. This scenario would be common when debugging LLDB or clang.

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

llvm-svn: 367726
2019-08-02 21:41:50 +00:00
Pavel Labath 23f70e8359 SymbolVendor: Introduce Module::GetSymbolFile
Summary:
This is the next step in avoiding funneling all SymbolFile calls through
the SymbolVendor. Right now, it is just a convenience function, but it
allows us to update all calls to SymbolVendor functions to access the
SymbolFile directly. Once all call sites have been updated, we can
remove the GetSymbolVendor member function.

This patch just updates the calls to GetSymbolVendor, which were calling
it just so they could fetch the underlying symbol file. Other calls will
be done in follow-ups.

Reviewers: JDevlieghere, clayborg, jingham

Subscribers: lldb-commits

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

llvm-svn: 367664
2019-08-02 08:16:35 +00:00
Pavel Labath e84f78412b Add llvm-style RTTI to ObjectFile hierarchy
Summary:
On the heels of D62934, this patch uses the same approach to introduce
llvm RTTI support to the ObjectFile hierarchy. It also replaces the
existing uses of GetPluginName doing run-time type checks with
llvm::dyn_cast and friends.

This formally introduces new dependencies from some other plugins to
ObjectFile plugins. However, I believe this is fine because:
- these dependencies were already kind of there, and the only reason
  we could get away with not modeling them explicitly was because the
  code was relying on magically knowing what will GetPluginName() return
  for a particular kind of object files.
- the dependencies themselves are logical (it makes sense for
  SymbolVendorELF to depend on ObjectFileELF), or at least don't
  actively get in the way (the JitLoaderGDB->MachO thing).
- they don't introduce any new dependency loops as ObjectFile plugins
  don't depend on any other plugins

Reviewers: xiaobai, JDevlieghere, espindola

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

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

llvm-svn: 367413
2019-07-31 11:57:34 +00:00
Pavel Labath d2deeb4490 SymbolVendor: Remove the object file member variable
Summary:
The last responsibility of the SymbolVendor was to hold an owning
reference to the object file (in case symbols are being read from a
different file than the main module). As SymbolFile classes already hold
a non-owning reference to the object file, we can easily remove this
responsibility of the SymbolVendor by making the SymbolFile reference
owning.

Reviewers: JDevlieghere, clayborg, jingham

Subscribers: lldb-commits

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

llvm-svn: 367392
2019-07-31 08:25:25 +00:00
Alex Langford 0e252e38ef [Symbol] Use llvm::Expected when getting TypeSystems
Summary:
This commit achieves the following:
- Functions used to return a `TypeSystem *` return an
  `llvm::Expected<TypeSystem *>` now. This means that the result of a call
  is always checked, forcing clients to move more carefully.
- `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a
  non-null pointer to a TypeSystem.

Reviewers: JDevlieghere, davide, compnerd

Subscribers: jdoerfert, lldb-commits

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

llvm-svn: 367360
2019-07-30 22:12:34 +00:00
Pavel Labath 656ddeb2b7 SymbolVendor: Move locking into the Symbol Files
Summary:
The last bit of functionality in SymbolVendor passthrough functions is
the locking the module mutex. While it may be nice doing the locking in
a central place, we weren't really succesful in doing that right now,
because some SymbolFile function could still be called without going
through the SymbolVendor. This meant in SymbolFileDWARF (the only
battle-tested symbol file implementation) roughly a half of the
functions was taking additional locks and another half was asserting
that the lock is already held. By making the SymbolFile responsible for
locking, we can at least make the situation in SymbolFileDWARF more
consistent.

Reviewers: clayborg, JDevlieghere, jingham, jdoerfert

Subscribers: aprantl, lldb-commits

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

llvm-svn: 367298
2019-07-30 08:20:05 +00:00
Pavel Labath c2409baa66 SymbolVendor: Make SectionAddressesChanged a passthrough
Summary:
This moves the implementation of the function into the SymbolFile class,
making it possible to excise the SymbolVendor passthrough functions in
follow-up patches.

Reviewers: clayborg, jingham, JDevlieghere

Subscribers: lldb-commits

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

llvm-svn: 367231
2019-07-29 15:53: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
Fangrui Song 2e959415d7 SymbolFile: Fix -Wunused-variable in -DLLVM_ENABLE_ASSERTIONS=off builds after D65089/r366791
llvm-svn: 367001
2019-07-25 09:56:45 +00:00
Pavel Labath f46e8974de SymbolVendor: Remove the type list member
Summary:
Similarly to the compile unit lists, the list of types can also be
managed by the symbol file itself.

Since the only purpose of this list seems to be to maintain an owning
reference to all the types a symbol file has created (items are only
ever added to the list, never retrieved), I remove the passthrough
functions in SymbolVendor and Module. I also tighten the interface of
the function (return a reference instead of a pointer, make it protected
instead of public).

Reviewers: clayborg, JDevlieghere, jingham

Subscribers: lldb-commits

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

llvm-svn: 366994
2019-07-25 08:22:05 +00:00
Alex Langford eb6782758a [Symbol] Fix some botched logic in Variable::GetLanguage
Summary:
I messed up the logic for this. Fixing with some improvements suggested
by Pavel.

Reviewers: labath, jdoerfert

Subscribers: lldb-commits

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

llvm-svn: 366950
2019-07-24 22:12:02 +00:00
Jonas Devlieghere 63e5fb76ec [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.

So instead of writing:

  if (log)
    log->Printf("%s\n", str);

You'd write:

  LLDB_LOG(log, "%s\n", str);

This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.

  find . -type f -name '*.cpp' -exec \
  sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +

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

llvm-svn: 366936
2019-07-24 17:56:10 +00:00
Pavel Labath 7c35db0865 Fix windows build after r366791
A side effect of this commit was that it exchanged the order of types
and compile units in the output of SymbolVendor::Dump. A couple of PDB
tests dependened on that to assert the links between the two.

While it wouldn't be too hard to update the tests, the change of
ordering was not something I intended to do with that patch, and is easy
to restore the original order, so I do just that.

llvm-svn: 366798
2019-07-23 12:26:09 +00:00
Pavel Labath e0119909a6 SymbolVendor: Move compile unit handling into the SymbolFile class
Summary:
SymbolFile classes are responsible for creating CompileUnit instances
and they already need to have a notion of the id<->CompileUnit mapping
(because of APIs like ParseCompileUnitAtIndex). However, the
SymbolVendor has remained as the thing responsible for caching created
units (which the SymbolFiles were calling via convoluted constructs like
"m_obj_file->GetModule()->GetSymbolVendor()->SetCompileUnitAtIndex(...)").

This patch moves the responsibility of caching the units into the
SymbolFile class. It does this by moving the implementation of
SymbolVendor::{GetNumCompileUnits,GetCompileUnitAtIndex} into the
equivalent SymbolFile functions. The SymbolVendor functions become just
a passthrough much like the rest of SymbolVendor.

The original implementations of SymbolFile::GetNumCompileUnits is moved
to "CalculateNumCompileUnits", and are made protected, as the "Get"
function is the external api of the class.
SymbolFile::ParseCompileUnitAtIndex is made protected for the same
reason.

This is the first step in removing the SymbolVendor indirection, as
proposed in
<http://lists.llvm.org/pipermail/lldb-dev/2019-June/015071.html>. After
removing all interesting logic from the SymbolVendor class, I'll proceed
with removing the indirection itself.

Reviewers: clayborg, jingham, JDevlieghere

Subscribers: jdoerfert, lldb-commits

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

llvm-svn: 366791
2019-07-23 09:24:02 +00:00
Alex Langford 4de5d9d612 [Symbol] Improve Variable::GetLanguage
Summary:
When trying to ascertain what language a variable belongs to, just
checking the compilation unit is often not enough. In r364845 I added a way to
check for a variable's language type, but didn't put it in Variable itself.
Let's go ahead and put it in Variable.

Reviewers: jingham, clayborg

Subscribers: jdoerfert, lldb-commits

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

llvm-svn: 366733
2019-07-22 20:14:18 +00:00
Joseph Tremoulet 3fd917d886 Support Linux signal return trampolines in frame initialization
Summary:
Add __kernel_rt_sigreturn to the list of trap handlers for Linux (it's
used as such on aarch64 at least), and __restore_rt as well (used on
x86_64).

Skip decrement-and-recompute for trap handlers in
InitializeNonZerothFrame, as signal dispatch may point the child frame's
return address to the start of the return trampoline.

Parse the 'S' flag for signal handlers from eh_frame augmentation, and
propagate it to the unwind plan.

Reviewers: labath, jankratochvil, compnerd, jfb, jasonmolenda

Reviewed By: jasonmolenda

Subscribers: clayborg, MaskRay, wuzish, nemanjai, kbarton, jrtc27, atanasyan, jsji, javed.absar, kristof.beyls, lldb-commits

Tags: #lldb

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

llvm-svn: 366580
2019-07-19 14:05:55 +00:00
Alex Langford bb0896970a [NFC] Remove instances of unused ClangASTContext header
llvm-svn: 366519
2019-07-19 00:39:51 +00:00
Shafik Yaghmour a0858e2f20 Fix CreateFunctionTemplateSpecialization to prevent dangling poiner to stack memory
In ClangASTContext::CreateFunctionTemplateSpecializationInfo a TemplateArgumentList is allocated on the stack but is treated as if it is persistent in subsequent calls. When we exit the function func_decl will still point to the stack allocated memory. We will use TemplateArgumentList::CreateCopy instead which will allocate memory out of the DeclContext.

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

llvm-svn: 366365
2019-07-17 20:16:13 +00:00
Alex Langford b5701710a4 [LanguageRuntime] Move ObjCLanguageRuntime into a plugin
Summary:
Following up to my CPPLanguageRuntime change, I'm moving
ObjCLanguageRuntime into a plugin as well.

Reviewers: JDevlieghere, compnerd, jingham, clayborg

Subscribers: mgorny, arphaman, lldb-commits

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

llvm-svn: 366148
2019-07-15 22:56:12 +00:00
Raphael Isemann 5ccdabf25d [lldb] Added assert to VerifyDecl
We could VerifyDecl sometimes with a nullptr. It would be nice if we
could get an actual assert here instead of triggering UB.

llvm-svn: 365247
2019-07-05 21:32:39 +00:00
Raphael Isemann c494481ea4 Add assert for 'bad' code path in GetUniqueNamespaceDeclaration
Summary:
If we call this function with a non-namespace as a second argument (and a nullptr name), we currently
only get a nullptr as a return when we hit the "Bad!!!" code path. This patch just adds an assert as this
seems to be a programming error in the calling code.

Reviewers: shafik

Subscribers: abidh, lldb-commits

Tags: #lldb

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

llvm-svn: 365157
2019-07-04 19:49:31 +00:00
Alex Langford 8055cbc449 [Symbol] Add DeclVendor::FindTypes
Summary:
Following up on the plan I outlined in D63622, we can remove the
dependence on clang in all the places where we only want to find the
types from the DeclVendor. This means that currently DeclVendor depends
on clang, but centralizing the dependency makes it easier to refactor
cleanly.

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

llvm-svn: 364962
2019-07-02 19:53:07 +00:00
Alex Langford d7fcee62f1 [Core] Generalize ValueObject::IsRuntimeSupportValue
Summary:
Instead of falling back to ObjCLanguageRuntime, we should be falling
back to every loaded language runtime. This makes ValueObject more
language agnostic.

Reviewers: labath, compnerd, JDevlieghere, davide

Subscribers: lldb-commits

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

llvm-svn: 364845
2019-07-01 20:36:33 +00:00
Jan Kratochvil 3f594ed168 Fix lookup of symbols at the same address with no size vs. size
This fixes a failing testcase on Fedora 30 x86_64 (regression Fedora 29->30):

PASS:
./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit
  * frame #0: 0x00007ffff7aa6e75 libc.so.6`__GI_raise + 325
    frame #1: 0x00007ffff7a91895 libc.so.6`__GI_abort + 295
    frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2
    frame #3: 0x000000000040113a a.out`func_b at main.c:18:2
    frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2
    frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2
    frame #6: 0x00007ffff7a92f33 libc.so.6`__libc_start_main + 243
    frame #7: 0x000000000040106e a.out`_start + 46

vs.

FAIL - unrecognized abort() function:
./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit
  * frame #0: 0x00007ffff7aa6e75 libc.so.6`.annobin_raise.c + 325
    frame #1: 0x00007ffff7a91895 libc.so.6`.annobin_loadmsgcat.c_end.unlikely + 295
    frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2
    frame #3: 0x000000000040113a a.out`func_b at main.c:18:2
    frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2
    frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2
    frame #6: 0x00007ffff7a92f33 libc.so.6`.annobin_libc_start.c + 243
    frame #7: 0x000000000040106e a.out`.annobin_init.c.hot + 46

The extra ELF symbols are there due to Annobin (I did not investigate why this problem happened specifically since F-30 and not since F-28).
It is due to:

Symbol table '.dynsym' contains 2361 entries:
Valu e          Size Type   Bind   Vis     Name
0000000000022769   5 FUNC   LOCAL  DEFAULT _nl_load_domain.cold
000000000002276e   0 NOTYPE LOCAL  HIDDEN  .annobin_abort.c.unlikely
...
000000000002276e   0 NOTYPE LOCAL  HIDDEN  .annobin_loadmsgcat.c_end.unlikely
...
000000000002276e   0 NOTYPE LOCAL  HIDDEN  .annobin_textdomain.c_end.unlikely
000000000002276e 548 FUNC   GLOBAL DEFAULT abort
000000000002276e 548 FUNC   GLOBAL DEFAULT abort@@GLIBC_2.2.5
000000000002276e 548 FUNC   LOCAL  DEFAULT __GI_abort
0000000000022992   0 NOTYPE LOCAL  HIDDEN  .annobin_abort.c_end.unlikely

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

llvm-svn: 364773
2019-07-01 14:31:26 +00:00
Fangrui Song a83e94ebf2 Use const auto *
llvm-svn: 364702
2019-06-29 00:55:13 +00:00
Jim Ingham f2128b28cd Get the expression parser to handle missing weak symbols.
MachO only for this patch.

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

<rdar://problem/51463642>

llvm-svn: 364686
2019-06-28 21:40:05 +00:00
Jason Molenda 868a394bb6 Don't link against the DebugSymbols private framework; try to dlopen
+ dlsym the two functions we need from there at runtime.

I'm not maintaining a negative cache if DebugSymbols is absent, so
we'll try to dlopen() it on every call to
LocateMacOSXFilesUsingDebugSymbols but this file is only built on
mac and iOS type systems, so there's a slight perf impact running
lldb on an iOS type system.

I store the function pointer results in two global variables without
any locking; two threads calling into LocateMacOSXFilesUsingDebugSymbols
for the first time will both try to set these fptrs, but they'll be
setting them to the same value, so I'm not too worried.

I didn't see where in the cmake build configurations we link against
DebugSymbols, but I removed the dependency from the xcode project
file.

<rdar://problem/49458356> 

llvm-svn: 364243
2019-06-24 22:08:43 +00:00
Jonas Devlieghere 28defa70ea Remove stale comment and disabled code (NFC)
llvm-svn: 363438
2019-06-14 18:12:55 +00:00
Gauthier Harnisch 796ed03b84 [C++20] add Basic consteval specifier
Summary:
this revision adds Lexing, Parsing and Basic Semantic for the consteval specifier as specified by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r3.html

with this patch, the consteval specifier is treated as constexpr but can only be applied to function declaration.

Changes:
 - add the consteval keyword.
 - add parsing of consteval specifier for normal declarations and lambdas expressions.
 - add the whether a declaration is constexpr is now represented by and enum everywhere except for variable because they can't be consteval.
 - adapt diagnostic about constexpr to print constexpr or consteval depending on the case.
 - add tests for basic semantic.

Reviewers: rsmith, martong, shafik

Reviewed By: rsmith

Subscribers: eraman, efriedma, rnkovacs, cfe-commits

Tags: #clang

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

llvm-svn: 363362
2019-06-14 08:56:20 +00:00
Pavel Labath d8aca8886f Make UniqueCStringMap work with non-default-constructible types and other improvements/cleanups
Summary:
The motivation for this was me wanting to make the validity of dwarf
DIERefs explicit (via llvm::Optional<DIERef>). This meant that the class
would no longer have a default constructor. As the DIERef was being
stored in a UniqueCStringMap, this meant that this container (like all
standard containers) needed to work with non-default-constructible types
too.

This part is achieved by removing the default constructors for the map
entry types, and providing appropriate comparison overloads so that we
can search for map entries without constructing a dummy entry. While
doing that, I took the opportunity to modernize the code, and add some
tests. Functions that were completely unused are deleted.

This required also some changes in the Symtab code, as it was default
constructing map entries, which was not impossible even though its
value type was default-constructible. Technically, these changes could
be avoided with some SFINAE on the entry type, but I felt that the code
is cleaner this way anyway.

Reviewers: JDevlieghere, sgraenitz

Subscribers: mgorny, aprantl, lldb-commits

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

llvm-svn: 363357
2019-06-14 06:33:31 +00:00
Pavel Labath ad805ef95a Recognise debug_types.dwo as a debug info section
This is a preparatory patch to allow reading type units from dwo files.

llvm-svn: 363146
2019-06-12 11:42:42 +00:00
Alex Langford e823bbe8d1 [Target] Remove Process::GetObjCLanguageRuntime
Summary:
In an effort to make Process more language agnostic, I removed
GetCPPLanguageRuntime from Process. I'm following up now with an equivalent
change for ObjC.

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

llvm-svn: 362981
2019-06-10 20:53:23 +00:00
Alex Langford a03e2b25ab [ABI] Fix SystemV ABI to handle nested aggregate type returned in register
Add a function to flatten the nested aggregate type

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

Patch by Wanyi Ye <kusmour@gmail.com>

llvm-svn: 362543
2019-06-04 19:29:59 +00:00
Pavel Labath 833dba01d9 Make CompileUnit::GetSupportFiles return a const list
There's no reason for anyone to modify a list from outside of a symbol
file (as that would break a lot of invariants that symbol files depend
on).

Make the function return a const FileSpecList and fix up a couple of
places that were needlessly binding non-const references to the result
of this function.

llvm-svn: 362069
2019-05-30 08:21:25 +00:00
Jonas Devlieghere 04a087ace7 [DWARFExpression] Remove ctor that takes just a compile unit.
Like many of our DWARF classes, the DWARFExpression can be initialized
in several ways. One such way was through a constructor that takes just
the compile unit. This constructor is used to initialize both empty
DWARFExpressions, and DWARFExpression that will be populated later.

To make the distinction more clear, I changed the constructor to a
default constructor and updated its call sites. Where the
DWARFExpression was being populated later, I replaced that with a call
to the copy assignment constructor.

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

llvm-svn: 361849
2019-05-28 17:34:05 +00:00
Pavel Labath ae4ec62cc9 FuncUnwinders: prefer debug_frame over eh_frame
The two sections usually contain the same information, and we rarely
have both kinds of entries for a single function. However, in theory the
debug_frame plan can be more complete, whereas eh_frame is only required
to be correct at places where exceptions can be thrown.

Reviewers: jasonmolenda, clayborg

Subscribers: lldb-commits

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

llvm-svn: 361758
2019-05-27 11:53:24 +00:00
Pavel Labath 1a0312ca0b [FuncUnwinders] Use "symbol file" unwind plans for unwinding
Summary:
Previous patch (r360409) introduced the "symbol file unwind plan"
concept, but that plan wasn't used for unwinding yet. With this patch,
we start to consider the new plan as a possible strategy for both
synchronous and asynchronous unwinding. I also add a test that asserts
that unwinding via breakpad STACK CFI info works end-to-end.

Reviewers: jasonmolenda, clayborg

Subscribers: lldb-commits, amccarth, markmentovai

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

llvm-svn: 361618
2019-05-24 09:54:39 +00:00
Jonas Devlieghere 09ad8c8f73 Fix integer literals which are cast to bool
This change replaces built-in types that are implicitly converted to
booleans.

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

llvm-svn: 361580
2019-05-24 00:44:33 +00:00
Konrad Kleine 248a13057a [lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]

This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.

This is the command I ran and I to fix and format the code base:

```
run-clang-tidy.py \
	-header-filter='.*' \
	-checks='-*,modernize-use-nullptr' \
	-fix ~/dev/llvm-project/lldb/.* \
	-format \
	-style LLVM \
	-p ~/llvm-builds/debug-ninja-gcc
```

NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.

NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.

Reviewers: martong, espindola, shafik, #lldb, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits

Tags: #lldb, #llvm

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

llvm-svn: 361484
2019-05-23 11:14:47 +00:00
Gabor Marton 37e6bf106c Add AST logging
Summary:
Log the AST of the TU associated with LLDB's `expr` command, once a declaration
is completed

Reviewers: shafik

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, lldb-commits

Tags: #lldb

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

llvm-svn: 361362
2019-05-22 09:10:19 +00:00
Alex Langford bceadcbb0c [Symbol] Remove dead code
llvm-svn: 361337
2019-05-22 00:06:44 +00:00
Alex Langford f7c4e6c6b1 [CMake] Correct some dependencies
Symbol doesn't depend on CPlusPlusLanguage, but Expressiond does.

llvm-svn: 361216
2019-05-21 03:41:05 +00:00
Fangrui Song 71a44224e5 Delete unnecessary copy ctors/copy assignment operators
It's the simplest and gives the cleanest semantics.

llvm-svn: 360762
2019-05-15 11:23:54 +00:00
Gabor Marton 5ac6d49065 [ASTImporter] Use llvm::Expected and Error in the importer API
Summary:
This is the final phase of the refactoring towards using llvm::Expected
and llvm::Error in the ASTImporter API.
This involves the following:
- remove old Import functions which returned with a pointer,
- use the Import_New functions (which return with Err or Expected) everywhere
  and handle their return value
- rename Import_New functions to Import
This affects both Clang and LLDB.

Reviewers: shafik, teemperor, aprantl, a_sidorin, balazske, a.sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits, lldb-commits

Tags: #clang, #lldb

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

llvm-svn: 360760
2019-05-15 10:29:48 +00:00
Fangrui Song b0e54cbcdf Fix file names in file headers. NFC
llvm-svn: 360554
2019-05-13 04:42:32 +00:00
Pavel Labath 22bbd7d690 FuncUnwinders: Add a new "SymbolFile" unwind plan
Summary:
some unwind formats are specific to a single symbol file and so it does
not make sense for their parsing code live in the general Symbol library
(as is the case with eh_frame for instance). This is the case for the
unwind information in breakpad files, but the same will probably be true
for PDB unwind info (once we are able to parse that).

This patch adds the ability to fetch an unwind plan provided by a symbol
file plugin, as discussed in the RFC at
<http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>.
I've kept the set of changes to a minimum, as there is no way to test
them until we have a symbol file which implements this API -- that is
comming in a follow-up patch, which will also implicitly test this
change.

The interesting part here is the introduction of the
"RegisterInfoResolver" interface. The reason for this is that breakpad
needs to be able to resolve register names (which are present as strings
in the file) into register enums so that it can construct the unwind
plan. This is normally done via the RegisterContext class, handing this
over to the SymbolFile plugin would mean that it has full access to the
debugged process, which is not something we want it to have. So instead,
I create a facade, which only provides the ability to query register
names, and hide the RegisterContext behind the facade.

Also note that this only adds the ability to dump the unwind plan
created by the symbol file plugin -- the plan is not used for unwinding
yet -- this will be added in a third patch, which will add additional
tests which makes sure the unwinding works as a whole.

Reviewers: jasonmolenda, clayborg

Subscribers: markmentovai, amccarth, lldb-commits

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

llvm-svn: 360409
2019-05-10 07:54:37 +00:00
Richard Smith 36851a66c8 Fix up lldb after clang r360311.
Patch by Tyker!

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

llvm-svn: 360312
2019-05-09 04:40:57 +00:00
Pavel Labath 0ff89dacaf PostfixExpression: Use signed integers in IntegerNode
Summary:
This is necessary to support parsing expressions like ".cfa -16 + ^", as
that format is used in breakpad STACK CFI expressions.

Since the PDB expressions use the same parser, this change will affect
them too, but I don't believe that should be a problem in practice. If
PDBs do contain the negative values, it's very likely that they are
intended to be parsed the same way, and if they don't, then it doesn't
matter.

In case that we do ever need to handle this differently, we can always
make the parser behavior customizable, or just use a different parser.

To make sure that the integer size is big enough for everyone, I switch
from using a (unsigned) 32-bit integer to a 64-bit (signed) one.

Reviewers: amccarth, clayborg, aleksandr.urakov

Subscribers: markmentovai, lldb-commits

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

llvm-svn: 360166
2019-05-07 15:58:20 +00:00
Krasimir Georgiev 435e76a558 [lldb] Add MacroQualified switch cases for r360109
Summary:
r360109 added a new enum case, causing lldb build to fail with several errors like:
lldb/source/Symbol/ClangASTContext.cpp:4342:11: error: enumeration value 'MacroQualified' not handled in switch [-Werror,-Wswitch]
  switch (qual_type->getTypeClass()) {
          ^
This adds the missing switch cases.
I'm not an lldb maintainer and just used my best judgement that it's probably expected that we break in these cases. Feel free to ping / revert / fix this change if this behavior is not appropriate.

Reviewers: gribozavr

Reviewed By: gribozavr

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

llvm-svn: 360146
2019-05-07 13:59:30 +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
Hans Wennborg d2b9fc88c8 Revert r359949 "[clang] adding explicit(bool) from c++2a"
This caused Clang to start erroring on the following:

  struct S {
    template <typename = int> explicit S();
  };

  struct T : S {};

  struct U : T {
    U();
  };
  U::U() {}

  $ clang -c /tmp/x.cc
  /tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T'
  U::U() {}
     ^
  /tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted
    because base class 'S' has no default constructor
  struct T : S {};
             ^
  1 error generated.

See discussion on the cfe-commits email thread.

This also reverts the follow-ups r359966 and r359968.

> this patch adds support for the explicit bool specifier.
>
> Changes:
> - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp.
> - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class.
> - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted.
> - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration.
> - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected.
> - Test for Semantic and Serialization were added.
>
> This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback.
> Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky.
>
> Patch by Tyker
>
> Differential Revision: https://reviews.llvm.org/D60934

llvm-svn: 360024
2019-05-06 09:51:10 +00:00
Nicolas Lesser 9c32fa1b1f [lldb] Fix buildbot failure due to clang AST change.
In r359949 several AST node constructors were modified without the
corresponding change in lldb, which caused build failures.

llvm-svn: 359966
2019-05-04 10:21:50 +00:00
Raphael Isemann 1756630dfa C.128 override, virtual keyword handling
Summary:
According to [C128] "Virtual functions should specify exactly one
of `virtual`, `override`, or `final`", I've added override where a
virtual function is overriden but the explicit `override` keyword
was missing. Whenever both `virtual` and `override` were specified,
I removed `virtual`. As C.128 puts it:

> [...] writing more than one of these three is both redundant and
> a potential source of errors.

I anticipate a discussion about whether or not to add `override` to
destructors but I went for it because of an example in [ISOCPP1000].
Let me repeat the comment for you here:

Consider this code:

```
    struct Base {
      virtual ~Base(){}
    };

    struct SubClass : Base {
      ~SubClass() {
        std::cout << "It works!\n";
      }
    };

    int main() {
      std::unique_ptr<Base> ptr = std::make_unique<SubClass>();
    }
```

If for some odd reason somebody removes the `virtual` keyword from the
`Base` struct, the code will no longer print `It works!`. So adding
`override` to destructors actively protects us from accidentally
breaking our code at runtime.

[C128]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c128-virtual-functions-should-specify-exactly-one-of-virtual-override-or-final
[ISOCPP1000]: https://github.com/isocpp/CppCoreGuidelines/issues/1000#issuecomment-476951555

Reviewers: teemperor, JDevlieghere, davide, shafik

Reviewed By: teemperor

Subscribers: kwk, arphaman, kadircet, lldb-commits

Tags: #lldb

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

llvm-svn: 359868
2019-05-03 10:03:28 +00:00
Adrian Prantl 1db0f0ca98 Hide runtime support values such as clang's __vla_expr from frame variable
by respecting the "artificial" attribute on variables. Function
arguments that are artificial and useful to end-users are being
whitelisted by the language runtime.

<rdar://problem/45322477>

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

llvm-svn: 359841
2019-05-02 23:07:23 +00:00
Raphael Isemann 9a0acdf65e Add std::stack and std::queue support to CxxModuleHandler
Reviewers: aprantl, shafik

Reviewed By: aprantl, shafik

Subscribers: lldb-commits

Tags: #c_modules_in_lldb, #lldb

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

llvm-svn: 359779
2019-05-02 11:25:50 +00:00
Raphael Isemann 3356c32098 Rename Minion to ASTImporterDelegate
Summary:
I think there universal agreement that Minion isn't the best name for this class. This patch renames the class
 to ASTImporterDelegate to better reflect it's goal of monitoring and extending the ASTImporter.

Reviewers: aprantl, shafik, martong, a.sidorin, davide

Reviewed By: aprantl, shafik, davide

Subscribers: rnkovacs, davide, abidh, lldb-commits

Tags: #lldb

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

llvm-svn: 359777
2019-05-02 10:58:33 +00:00
Jonas Devlieghere 2795490b1a Sort Symbol/CMakeLists.txt
This makes resolving merge conflicts downstream a tad easier.

llvm-svn: 359577
2019-04-30 17:22:29 +00:00
Pavel Labath 03db32b303 PostfixExpression: Introduce InitialValueNode
Summary:
This node represents can be used to refer to the initial value, which is
sometimes pushed onto the DWARF stack as the "input" to the DWARF
expression. The typical use case (and the reason why I'm introducing it)
is that the "Canonical Frame Address" is passed this way to the DWARF
expressions computing the values of registers during frame unwind.

The nodes are converted into dwarf by keeping track of DWARF stack depth
an any given point, and then copying the initial value from the bottom
of the stack via the DW_OP_pick opcode. This could be made more
efficient for simple expressions, but here I chose to start with the
most general implementation possible.

Reviewers: amccarth, clayborg, aleksandr.urakov

Subscribers: aprantl, jasonmolenda, lldb-commits, markmentovai

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

llvm-svn: 359560
2019-04-30 13:33:18 +00:00
Raphael Isemann 9a7ccd01b6 Sort containers alphabetically in CxxModuleHandler [NFC]
llvm-svn: 359546
2019-04-30 10:27:31 +00:00
Raphael Isemann f74a4c1f6d Instantiate 'std' templates explicitly in the expression evaluator
Summary:
This patch is a follow-up for D58125. It implements the manual instantiation and merging of 'std' templates like
`std::vector` and `std::shared_ptr` with information from the debug info AST. This (finally) allows using these classes
in the expression evaluator like every other class (i.e. things like `vec.size()` and shared_ptr debugging now works, yay!).

The main logic is the `CxxModuleHandler` which intercept the ASTImporter import process and replaces any `std` decls
by decls from the C++ module. The decls from the C++ module are "imported" by just deserializing them directly in
the expression evaluation context. This is mostly because we don't want to rely on the ASTImporter to correctly import
these declarations, but in the future we should also move to the ASTImporter for that.

This patch doesn't contain the automatic desugaring for result variables. This means that if you call for example
`size` of `std::vector` you maybe get some very verbose typedef'd type as the variable type, e.g.
`std::vector<int, std::allocator<int>>::value_type`.

This is not only unreadable, it also means that our ASTImporter has to import all these types and associated
decls into the persisent variable context. This currently usually leads to some assertion getting triggered
in Clang when the ASTImporter either makes a mistake during importing or our debug info AST is inconsitent.
The current workaround I use in the tests is to just cast the result to it's actual type (e.g. `size_t` or `int`) to prevent
the ASTImporter from having to handle all these complicated decls.

The automatic desugaring will be a future patch because I'm not happy yet with the current code for that and because
I anticipate that this will be a controversial patch.

Reviewers: aprantl, shafik, jingham, martong, serge-sans-paille

Reviewed By: martong

Subscribers: balazske, rnkovacs, mgorny, mgrang, abidh, jdoerfert, lldb-commits

Tags: #c_modules_in_lldb, #lldb

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

llvm-svn: 359538
2019-04-30 08:41:35 +00:00
Pavel Labath 0eadd98866 PostfixExpression: move DWARF generator out of NativePDB internals
Summary:
The new dwarf generator is pretty much a verbatim copy of the one in
PDB.

In order to write a pdb-independent test for it, I needed to write a
dummy "symbol resolver", which (together with the fact that I'll need
one more for breakpad-specific resolution logic) prompted me to create a
more simple interface for algorithms which replace or "resolve"
SymbolNodes. The resolving algorithms in NativePDB have been updated to
make use of that too.

I have removed a couple of NativePDB tests which weren't testing
anything pdb-specific and where the tested functionality was covered by
the new format-agnostic tests I have added.

Reviewers: amccarth, clayborg, aleksandr.urakov

Subscribers: aprantl, markmentovai, lldb-commits, jasonmolenda, JDevlieghere

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

llvm-svn: 359288
2019-04-26 08:52:04 +00:00
Pavel Labath 88813103cd PostfixExpression: move parser out of NativePDB internals
Summary:
The postfix expressions in PDB and breakpad symbol files are similar
enough that they can be parsed by the same parser. This patch
generalizes the parser in the NativePDB plugin and moves it into the
PostfixExpression file created in the previous commit (r358976).

The generalization consists of treating any unrecognised token as a
"symbol" node (previously these would only be created for tokens
starting with "$", and other token would abort the parse). This is
needed because breakpad symbols can also contain ".cfa" tokens, which
refer to the frame's CFA.

The cosmetic changes include:
- using a factory function instead of a class for creating nodes (this
  is more generic as it allows the same BumpPtrAllocator to be used for
  other things too)
- using dedicated function for parsing operator tokens instead of a
  DenseMap (more efficient as we don't need to create the DenseMap every
  time).

Reviewers: amccarth, clayborg, JDevlieghere, aleksandr.urakov

Subscribers: jasonmolenda, lldb-commits, markmentovai, mgorny

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

llvm-svn: 359073
2019-04-24 07:27:05 +00:00
Pavel Labath 2359429168 FuncUnwinders: remove "current_offset" from function arguments
Summary:
This argument was added back in 2010 (r118882) to support the ability to unwind
from functions whose eh_frame entry does not cover the entire range of
the function.

However, due to the caching happening in FuncUnwinders, this solution is
very fragile. FuncUnwinders will cache the plan it got from eh_frame
regardless of the value of the current_offset, so our ability to unwind
from a given function depended what was the value of "current_offset" the
first time that this function was called.

Furthermore, since the "image show-unwind" command did not know what's
the right offset to pass, this created an unfortunate situation where
"image show-unwind" would show no valid plans for a function, even
though they were available and being used.

In this patch I implement the feature slightly differently. Instead of
giving just a base address to the eh_frame unwinder, I give it the
entire range we are interested in. Then, I change the unwinder to return
the first plan that covers (even partially) that range. This way even a
partial plan will be returned, regardless of the address in the function
where we are stopped at.

This solution is still not 100% correct, as it will not handle a
function which is covered by two independent fde entries. However, I
don't expect anybody will write this kind of functions, and this wasn't
handled by the previous implementation either. If this is ever needed in
the future. The eh_frame unwinder can be extended to return "composite"
unwind plans created by merging sevelar fde entries.

I also create a test which triggers this scenario. As doing this is
virtually impossible without hand-written assembly, the test only works
on x86 linux.

Reviewers: jasonmolenda, clayborg

Subscribers: lldb-commits

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

llvm-svn: 358964
2019-04-23 09:57:14 +00:00
Pavel Labath 7a78420353 UnwindPlan: pretty-print dwarf expressions
Summary:
Previously we were printing the dwarf expressions in unwind rules simply
as "dwarf-expr". This patch uses the existing dwarf-printing
capabilities in lldb to enhance this dump output, and print the full
decoded dwarf expression.

Reviewers: jasonmolenda, clayborg

Subscribers: aprantl, lldb-commits

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

llvm-svn: 358959
2019-04-23 09:16:51 +00:00
Raphael Isemann bef588ce11 Fix typo in ArmUnwindInfo::GetUnwindPlan
Summary:
As reported in LLVM bug 41486, the check `(byte1 & 0xf8) == 0xc0` is wrong. We want to check for `11010nnn`,
so the proper value we want to compare against is `0xd0` (`0xc0` would check for the value `11000nnn` which we
already checked for above as described in the bug report).

Reviewers: #lldb, jasonmolenda

Reviewed By: #lldb, jasonmolenda

Subscribers: jasonmolenda, javed.absar, kristof.beyls, lldb-commits

Tags: #lldb

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

llvm-svn: 358479
2019-04-16 08:06:56 +00:00
Jonas Devlieghere 8b3af63b89 [NFC] Remove ASCII lines from comments
A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.

I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.

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

llvm-svn: 358135
2019-04-10 20:48:55 +00:00
Pavel Labath 9876addcf4 Remove the TypePair class
Summary:
After D59297, the TypePair class kind of lost its purpose as it was no
longer a "pair". This finishes the job started in that patch and deletes
the class altogether. All usages have been updated to use CompilerType
class directly.

Reviewers: clayborg, jingham, zturner

Subscribers: mehdi_amini, dexonsmith, jdoerfert, lldb-commits

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

llvm-svn: 356993
2019-03-26 13:35:54 +00:00
Raphael Isemann 5e3a7698e8 Remove the unused return value in ASTImporter::Imported [NFC]
Summary:
`ASTImporter::Imported` currently returns a Decl, but that return value is not used by the ASTImporter (or anywhere else)
nor is it documented.

Reviewers: balazske, martong, a.sidorin, shafik

Reviewed By: balazske, martong

Subscribers: rnkovacs, cfe-commits

Tags: #clang

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

llvm-svn: 356592
2019-03-20 19:00:25 +00:00
Pavel Labath dec963921b Reinitialize UnwindTable when the SymbolFile changes
Summary:
This is a preparatory step to enable adding of unwind plans by symbol
file plugins.

Although at the surface it seems that currently symbol files have
nothing to do with unwinding, this isn't entirely correct even now. The
mere act of adding a symbol file can have the effect of making more
sections (typically .debug_frame) available to the unwinding machinery,
so that it can have more unwind strategies to choose from.

Up until now, we've had a bug, which went largely unnoticed, where
unwind info in the manually added symbols files (target symbols add) was
being ignored during unwinding. Reinitializing the UnwindTable fixes
that bug too.

Reviewers: clayborg, jasonmolenda, alexshap

Subscribers: jdoerfert, lldb-commits

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

llvm-svn: 356361
2019-03-18 10:45:02 +00:00
Pavel Labath a933d6c7c0 Delete type_sp member from TypePair
Summary:
As discussed in the review of D59217, this member is unnecessary since
always the first thing we do is convert it to a CompilerType.

This opens up possibilities for further cleanups (e.g. the whole
TypePair class now loses purpose, since we can just pass around
CompilerType everywhere), but I did not want to do that yet, because I
am not sure if this will not introduce breakages in some of the
platforms/configurations that I am not testing on.

Reviewers: clayborg, zturner, jingham

Subscribers: jdoerfert, lldb-commits

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

llvm-svn: 356262
2019-03-15 14:02:35 +00:00
Raphael Isemann a946997c24 Correctly look up declarations in inline namespaces
Summary:
This patch marks the inline namespaces from DWARF as inline and also ensures that looking
up declarations now follows the lookup rules for inline namespaces.

Reviewers: aprantl, shafik, serge-sans-paille

Reviewed By: aprantl

Subscribers: eraman, jdoerfert, lldb-commits

Tags: #c_modules_in_lldb, #lldb

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

llvm-svn: 355897
2019-03-12 07:45:04 +00:00
Adrian Prantl 0c72a42a8f Add an LLVM-style dump method to CompilerType for extra convenience during debugging
This change has no effect on Release (NoAsserts) builds.

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

llvm-svn: 355632
2019-03-07 20:20:02 +00:00
Adrian Prantl 28f7466f4e Promote more debug-only assertions to regular assertions.
llvm-svn: 355569
2019-03-07 00:14:20 +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
Zachary Turner a89ce43cec Resubmit "Don't include UnixSignals.h from Host."
This was reverted because it breaks the GreenDragon bot, but
the reason for the breakage is lost, so I'm resubmitting this
now so we can find out what the problem is.

llvm-svn: 355528
2019-03-06 18:20:23 +00:00
Jason Molenda e772052edf Increase timeout in Symbols::DownloadObjectAndSymbolFile
from 30 seconds to 120 seconds.  We've seen cases where
this symbol lookup can exceed 30 seconds for people
working remotely.

<rdar://problem/48460476> 

llvm-svn: 355169
2019-03-01 03:24:59 +00:00
Zachary Turner 80552918a9 Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cpp
Given that we have a target named Symbols, one wonders why a
file named Symbols.cpp is not in this target.  To be clear,
the functions exposed from this file are really focused on
*locating* a symbol file on a given host, which is where the
ambiguity comes in.  However, it makes more sense conceptually
to be in the Symbols target. While some of the specific places
to search for symbol files might change depending on the Host,
this is not inherently true in the same way that, for example,
"accessing the file system" or "starting threads" is
fundamentally dependent on the Host.

PDBs, for example, recently became a reality on non-Windows platforms,
and it's theoretically possible that DSYMs could become a thing on non
MacOSX platforms (maybe in a remote debugging scenario). Other types of
symbol files, such as DWO, DWP, etc have never been tied to any Host
platform anyway.

After this patch, there is only one remaining dependency from
Host to Target.

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

llvm-svn: 355032
2019-02-27 21:42:10 +00:00
Jonas Devlieghere 9764b65c82 [Reproducers] Make clang use lldb's VFS.
In r353906 we hooked up clang and lldb's reproducer infrastructure to
capture files used by clang. This patch adds the necessary logic to have
clang reuse the files from lldb's reproducer during replay.

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

llvm-svn: 354283
2019-02-18 20:31:18 +00:00
Richard Smith 35b007e9a9 Fix AST generated for a class template to connect the class inside a
class template back to the template.

Previously, when the ASTImporter imported the class, it didn't know that
it was the pattern of a class template, so made the class a name lookup
result for the name of the template, resulting in ambiguity errors when
naming the template.

Due to a clang bug (fixed in r354091, reverted and soon to be
re-committed), ambiguity errors between a template and a non-template
were previously not diagnosed. Once r354091 is re-committed, this will
be covered by existing lldb tests.

llvm-svn: 354173
2019-02-15 21:48:09 +00:00
Pavel Labath 66d88326ab Move UnwindTable from ObjectFile to Module
Summary:
This is a preparatory step to enable adding extra unwind strategies by
symbol file plugins. This has been discussed on the lldb-dev mailing
list: <http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>.

Reviewers: jasonmolenda, clayborg, espindola

Subscribers: lemo, emaste, lldb-commits, arichardson

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

llvm-svn: 354033
2019-02-14 14:40:10 +00:00
Adrian Prantl 0f30a3b68f Deserialize Clang module search path from DWARF
This patch properly extracts the full submodule path as well as its
search paths from DWARF import decls and passes it on to the
ClangModulesDeclVendor.

rdar://problem/47970144

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

llvm-svn: 353961
2019-02-13 18:10:41 +00:00
Jonas Devlieghere d5b440369d Replace 'ap' with 'up' suffix in variable names. (NFC)
The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.

In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.

I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.

llvm-svn: 353912
2019-02-13 06:25:41 +00:00
Jonas Devlieghere 70355ace3f Remove redundant ::get() for smart pointer. (NFC)
This commit removes redundant calls to smart pointer’s ::get() method.

https://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-smartptr-get.html

llvm-svn: 353795
2019-02-12 03:47:39 +00:00
Jonas Devlieghere 796ac80b86 Use std::make_shared in LLDB (NFC)
Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared to ::reset(new), it also performs a single
heap allocation for the object and control block.

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

llvm-svn: 353764
2019-02-11 23:13:08 +00:00
Aleksandr Urakov 40624a085c [Expressions] Add support of expressions evaluation in some object's context
Summary:
This patch adds support of expression evaluation in a context of some object.
Consider the following example:
```
struct S {
  int a = 11;
  int b = 12;
};

int main() {
  S s;
  int a = 1;
  int b = 2;
  // We have stopped here
  return 0;
}
```
This patch allows to do something like that:
```
lldb.frame.FindVariable("s").EvaluateExpression("a + b")
```
and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be
used (not locals `a` and `b`).

This is achieved by replacing of `this` type and object for the expression. This
has some limitations: an expression can be evaluated only for values located in
the debuggee process memory (they must have an address of `eAddressTypeLoad`
type).

Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille

Reviewed By: jingham

Subscribers: abidh, lldb-commits, leonid.mashinskiy

Tags: #lldb

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

llvm-svn: 353149
2019-02-05 09:14:36 +00:00
Shafik Yaghmour 1849dd4acc Fix handling of CreateTemplateParameterList when there is an empty pack
Summary:
When we are creating a ClassTemplateSpecializationDecl in ParseTypeFromDWARF(...) we are not handling the case where variadic pack is empty in the specialization. This patch handles that case and adds a test to prevent future regressions.

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

llvm-svn: 352677
2019-01-30 21:48:56 +00:00
Adrian Prantl d13777aa18 Make Type::GetByteSize optional (NFC)
This is a continuation of my quest to make the size 0 a supported value.

This reapplies r352394 with additional PDB parser fixes prepared by
Pavel Labath!

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

llvm-svn: 352521
2019-01-29 17:52:34 +00:00
Adrian Prantl 2a56e97f74 Revert "Make Type::GetByteSize optional (NFC)"
This reverts commit r352394 because it broke three windows-specific tests.

llvm-svn: 352434
2019-01-28 21:44:35 +00:00
Adrian Prantl c56779b5fc Remove unimplemented function
Looks like this was an unintended sideeffect of r124250.

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

llvm-svn: 352417
2019-01-28 19:38:08 +00:00
Adrian Prantl 729fcf1793 Make Type::GetByteSize optional (NFC)
This is a continuation of my quest to make the size 0 a supported value.

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

llvm-svn: 352394
2019-01-28 17:49:33 +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
Pavel Labath 7630e0bcbe Recommit "Teach the default symbol vendor to respect module.GetSymbolFileFileSpec()"
This reapplies commit r351330, which was reverted due to a failing test on
macos. The failure was because the SymbolVendor used on MacOS was stricter than
the default (or ELF) symbol vendor, and rejected the symbol file because it's
UUID did not match the object file.

This version of the patch adds a uuid load command to the test macho file to
make sure the UUIDs match.

llvm-svn: 351447
2019-01-17 15:07:35 +00:00
Adrian Prantl 2ee7b881a0 Change TypeSystem::GetBitSize() to return an optional result.
This patch changes the behavior when printing C++ function references:
where we previously would get a <could not determine size>, there is
now a <no summary available>. It's not clear to me whether this is a
bug or an omission, but it's one step further than LLDB previously
got.

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

llvm-svn: 351376
2019-01-16 21:19:20 +00:00
Pavel Labath d38bd4ee82 Revert "Teach the default symbol vendor to respect module.GetSymbolFileFileSpec()"
This reverts commit r351330 due to failures on MacOS bots.

llvm-svn: 351353
2019-01-16 16:09:13 +00:00
Pavel Labath dd487d6521 Teach the default symbol vendor to respect module.GetSymbolFileFileSpec()
Summary:
Adding a breakpad symbol file to an existing MachO module with "target symbols
add" currently works only if one's host platform is a mac. This is
because SymbolVendorMacOSX (which is the one responsible for loading
symbols for MachO files) is conditionally compiled for the mac platform.

While we will sooner or later have a special symbol vendor for breakpad
files (to enable more advanced searching), and so this flow could be
made to work through that, it's not clear to me whether this should be a
requirement for the "target symbols add" flow to work. After all, since
the user has explicitly specified the symbol file to use, the symbol
vendor plugin's job is pretty much done.

This patch teaches the default symbol vendor to respect module's symbol
file spec, and load the symbol from that file if it is specified (and no
plugin requests any special handling).

Reviewers: clayborg, zturner, lemo

Subscribers: lldb-commits

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

llvm-svn: 351330
2019-01-16 12:42:57 +00:00
Adrian Prantl 2f1fa7a027 Simplify code
llvm-svn: 351244
2019-01-15 21:04:19 +00:00
Adrian Prantl d6a9bbf68e Replace auto -> llvm::Optional<uint64_t>
This addresses post-commit feedback for https://reviews.llvm.org/D56688

llvm-svn: 351237
2019-01-15 20:33:58 +00:00
Adrian Prantl d963a7c398 Make CompilerType::getBitSize() / getByteSize() return an optional result. NFC
The code in LLDB assumes that CompilerType and friends use the size 0
as a sentinel value to signal an error. This works for C++, where no
zero-sized type exists, but in many other programming languages
(including I believe C) types of size zero are possible and even
common. This is a particular pain point in swift-lldb, where extra
code exists to double-check that a type is *really* of size zero and
not an error at various locations.

To remedy this situation, this patch starts by converting
CompilerType::getBitSize() and getByteSize() to return an optional
result. To avoid wasting space, I hand-rolled my own optional data
type assuming that no type is larger than what fits into 63
bits. Follow-up patches would make similar changes to the ValueObject
hierarchy.

rdar://problem/47178964

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

llvm-svn: 351214
2019-01-15 18:07:52 +00:00
Zachary Turner 576495e67b [SymbolFile] Remove SymbolContext parameter from FindTypes.
This parameter was only ever used with the Module set, and
since a SymbolFile is tied to a module, the parameter turns
out to be entirely unnecessary.  Furthermore, it doesn't make
a lot of sense to ask a caller to ask SymbolFile which is tied
to Module X to find types for Module Y, but that possibility
was open with the previous interface.  By removing this
parameter from the API, it makes it harder to use incorrectly
as well as easier for an implementor to understand what it
needs to do.

llvm-svn: 351133
2019-01-14 22:41:21 +00:00
Zachary Turner c0a246afbe [SymbolFile] Remove the SymbolContext parameter from FindNamespace.
Every callsite was passing an empty SymbolContext, so this parameter
had no effect.  Inside the DWARF implementation of this function,
however, there was one codepath that checked members of the
SymbolContext.  Since no call-sites actually ever used this
functionality, it was essentially dead code, so I've deleted this
code path as well.

llvm-svn: 351132
2019-01-14 22:41:00 +00:00
Zachary Turner ffc1b8fd76 [SymbolFile] Rename ParseFunctionBlocks to ParseBlocksRecursive.
This method took a SymbolContext but only actually cared about the
case where the m_function member was set.  Furthermore, it was
intended to be implemented to parse blocks recursively despite not
documenting this in its name.  So we change the name to indicate
that it should be recursive, while also limiting the function
parameter to be a Function&.  This lets the caller know what is
required to use it, as well as letting new implementers know what
kind of inputs they need to be prepared to handle.

llvm-svn: 351131
2019-01-14 22:40:41 +00:00
Zachary Turner 863f8c18b9 [SymbolFile] Make ParseCompileUnitXXX accept a CompileUnit&.
Previously all of these functions accepted a SymbolContext&.
While a CompileUnit is one member of a SymbolContext, there
are also many others, and by passing such a monolithic parameter
in this way it makes the requirements and assumptions of the
API unclear for both callers as well as implementors.

All these methods need is a CompileUnit.  By limiting the
parameter type in this way, we simplify the code as well as
make it self-documenting for both implementers and users.

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

llvm-svn: 350943
2019-01-11 18:03:20 +00:00
Pavel Labath 1cf23e1a37 Introduce SymbolFileBreakpad and use it to fill symtab
Summary:
This commit adds the glue code necessary to integrate the
SymbolFileBreakpad into the plugin system. Most of the methods are
stubbed out. The only method implemented method is AddSymbols, which
parses the PUBLIC "section" of the breakpad "object file", and fills out
the Module's symtab.

To enable testing this, I've made two additional changes:
- dump Symtab from the SymbolVendor class. The symtab was already being
  dumped as a part of the object file dump, but that happened before
  symbol vendor kicked in, so it did not reflect any symbols added
  there.
- add ability to explicitly specify the external symbol file in
  lldb-test (so that the object file could be linked with the breakpad
  symbol file). To make things simpler, I've changed lldb-test from
  consuming multiple inputs (and dumping their symbols) to having it
  just process a single file per invocation. This was not a problem
  since everyone was using it that way already.

Reviewers: clayborg, zturner, lemo, markmentovai, amccarth

Subscribers: mgorny, lldb-commits

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

llvm-svn: 350924
2019-01-11 11:17:51 +00:00
Zachary Turner ac0d41c760 Change SymbolFile::ParseTypes to ParseTypesForCompileUnit.
The function SymbolFile::ParseTypes previously accepted a SymbolContext.
This makes it extremely difficult to implement faithfully, because you
have to account for all possible combinations of members being set in
the SymbolContext. On the other hand, no clients of this function
actually care about implementing this function to this strict of a
standard. AFAICT, there is actually only 1 client in the entire
codebase, and it is the function ParseAllDebugSymbols, which is itself
only called for testing purposes when dumping information. At this
call-site, the only field it sets is the CompileUnit, meaning that an
implementer of a SymbolFile need not worry about any examining or
handling any other fields which might be set.

By restricting this API to accept exactly a CompileUnit& and nothing
more, we can simplify the life of new SymbolFile plugin implementers by
making it clear exactly what the necessary and sufficient set of
functionality they need to implement is, while at the same time removing
some dead code that tried to handle other types of SymbolContext fields
that were never going to be set anyway.

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

llvm-svn: 350889
2019-01-10 20:57:50 +00:00
Jonas Devlieghere 9bbba276e9 Change std::sort to llvm::sort to detect non-determinism.
LLVM added wrappers to std::sort (r327219) that randomly shuffle the
container before sorting. The goal is to uncover non-determinism due to
undefined sorting order of objects having the same key.

This can be enabled with -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON.

llvm-svn: 350679
2019-01-08 23:25:06 +00:00
Jonas Devlieghere 8edd8e31eb [SymbolContext] Remove dead code
Removes two methods from SymbolContextList that aren't referenced.

llvm-svn: 350599
2019-01-08 01:35:00 +00:00
Pavel Labath 232ab01e6b Symtab: Remove one copy of symbol size computation code
Summary:
The implementation in CalculateSymbolSizes has been made redundant in
D19004, as this patch added another copy of size computation code into
InitAddressIndexes (which is called by CalculateSymbolSizes).

Reviewers: clayborg, jasonmolenda, tberghammer

Subscribers: lldb-commits

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

llvm-svn: 350384
2019-01-04 10:11:25 +00:00
Pavel Labath f760f5aef4 Simplify ObjectFile::GetArchitecture
Summary:
instead of returning the architecture through by-ref argument and a
boolean value indicating success, we can just return the ArchSpec
directly. Since the ArchSpec already has an invalid state, it can be
used to denote the failure without the additional bool.

Reviewers: clayborg, zturner, espindola

Subscribers: emaste, arichardson, JDevlieghere, lldb-commits

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

llvm-svn: 350291
2019-01-03 10:37:19 +00:00
Davide Italiano e4c9120499 [Type] Simplify operator!=. NFC.
llvm-svn: 350164
2018-12-30 15:08:51 +00:00
Davide Italiano 9470c66ced [TypeName] Simplify operator!=. NFCI.
llvm-svn: 350163
2018-12-30 15:07:25 +00:00
Davide Italiano 223032f72e [CompilerType] Simplify operator!=. NFCI.
llvm-svn: 350148
2018-12-29 05:00:33 +00:00
Davide Italiano e70af020f4 [CompilerType] Remove dead code. NFCI.
llvm-svn: 350147
2018-12-29 04:59:07 +00:00
Davide Italiano d22327080c [SymbolContext] Rewrite operator== to be more concise.
And probably, less error prone. NFCI.

llvm-svn: 350146
2018-12-29 04:57:00 +00:00
Pavel Labath ffec31e462 Remove unused variable from ClangASTContext
llvm-svn: 350121
2018-12-28 13:34:44 +00:00
Jonas Devlieghere 8d20cfdfc6 [NFC] Replace `compare` with (in)equality operator where applicable.
Using compare is verbose, bug prone and potentially inefficient (because
of early termination). Replace relevant call sites with the (in)equality
operator.

llvm-svn: 349972
2018-12-21 22:46:10 +00:00
Zachary Turner 1639c6bbb1 [Clang AST Context] Add a few helper functions.
The first one allows us to add an enumerator to an enum if we
already have an APSInt, since ultimately the implementation just
constructs one anyway.  The second is just a general utility
function to covert a CompilerType to a clang::TagDecl.

llvm-svn: 349360
2018-12-17 16:15:13 +00:00
Jonas Devlieghere a6682a413d Simplify Boolean expressions
This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:

run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD

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

llvm-svn: 349215
2018-12-15 00:15:33 +00:00
Zachary Turner d3d2b9b891 [NativePDB] Add support for local variables.
This patch adds support for parsing and evaluating local variables.
using the native pdb plugin.

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

llvm-svn: 349067
2018-12-13 18:17:51 +00:00
Mikael Nilsson 8b3bf6c173 Fix for clang interface update
FunctionProtoType.TypeQuals is now a Qualifiers object instead of an
integer.

The related clang commit: r349019

llvm-svn: 349020
2018-12-13 10:17:26 +00:00
Zachary Turner 6753d2d180 [ast] CreateParameterDeclaration should use an appropriate DeclContext.
Previously CreateParameterDeclaration was always using the translation
unit DeclContext.  We would later go and add parameters to the
FunctionDecl, but internally clang makes a copy when you do this, and
we'd end up with ParmVarDecl's at the global scope as well as in the
function scope.

This fixes the issue.  It's hard to say whether this will introduce
a behavioral change in name lookup, but I know there have been several
hacks introduced in previous years to deal with collisions between
various types of variables, so there's a chance that this patch could
obviate one of those hacks.

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

llvm-svn: 348941
2018-12-12 17:17:53 +00:00
Pavel Labath d1e3fe2190 Rename ObjectFile::GetHeaderAddress to GetBaseAddress
Summary:
This function was named such because in the case of MachO files, the
mach header is located at this address. However all (most?) usages of
this function were not interested in that fact, but the fact that this
address is used as the base address for expressing various relative
addresses in the object file.

For other object file formats, this name is not appropriate (and it's
probably the reason why this function was not implemented in these
classes). In the ELF case the ELF header will usually end up at this
address, but this is a result of the linker optimizing the file layout
and not a requirement of the spec. For COFF files, I believe the is no
header located at this address either.

Reviewers: clayborg, jasonmolenda, amccarth, lemo, stella.stamenova

Subscribers: lldb-commits

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

llvm-svn: 348849
2018-12-11 15:21:15 +00:00
Zachary Turner 9d76e42014 Fix undefined behavior in Variable.h
m_loc_is_constant_data was uninitialized, so unless someone
explicitly called SetLocIsConstantData(), this would be UB.

I think every existing call-site would always call the proper
function to initialize the value, so there were no existing
bugs, but I encountered this when I tried to use it without
calling this function and encountered this.

llvm-svn: 348813
2018-12-11 00:15:03 +00:00
Pavel Labath 1f6b247717 Re-commit "Introduce ObjectFileBreakpad"
This re-commits r348592, which was reverted due to a failing test on
macos.

The issue was that I was passing a null pointer for the
"CreateMemoryInstance" callback when registering ObjectFileBreakpad,
which caused crashes when attemping to load modules from memory. The
correct thing to do is to pass a callback which always returns a null
pointer (as breakpad files are never loaded in inferior memory).

It turns out that there is only one test which exercises this code path,
and it's mac-only, so I've create a new test which should run everywhere
(except windows, as one cannot delete an executable which is being run).
Unfortunately, this test still fails on linux for other reasons, but at
least it gives us something to aim for.

The original commit message was:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information

A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +

Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).

In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.

Reviewers: clayborg, zturner, lemo, amccarth

Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits

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

llvm-svn: 348773
2018-12-10 17:16:38 +00:00
Shafik Yaghmour 48c7b4f0b6 Revert "Introduce ObjectFileBreakpad"
This reverts commit 5e056e624cc57bb22a4c29a70b522783c6242293.

Reverting because this lldb cmake bot: http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/13712/

llvm-svn: 348629
2018-12-07 18:59:00 +00:00
Pavel Labath d6e6e232ec Introduce ObjectFileBreakpad
Summary:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information

A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +

Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).

In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.

Reviewers: clayborg, zturner, lemo, amccarth

Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits

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

llvm-svn: 348592
2018-12-07 14:20:27 +00:00
Aleksandr Urakov 8cfb12b9bd [Symbol] Search symbols with name and type in a symbol file
Summary:
This patch adds possibility of searching a public symbol with name and type in
a symbol file, not only in a symtab. It is helpful when working with PE, because
PE's symtabs contain only imported / exported symbols only. Such a search is
required for e.g. evaluation of an expression that calls some function of
the debuggee.

Reviewers: zturner, asmith, labath, clayborg, espindola

Reviewed By: clayborg

Subscribers: davide, emaste, arichardson, aleksandr.urakov, jingham,
             lldb-commits, stella.stamenova

Tags: #lldb

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

llvm-svn: 347960
2018-11-30 06:56:37 +00:00
Hans Wennborg 30ce962732 Revert r347673 "Catch up with EvaluateAsInt() clang API change."
r347417 was re-committed in Clang.

llvm-svn: 347758
2018-11-28 14:30:18 +00:00
Davide Italiano 6b2f3e07c6 Catch up with EvaluateAsInt() clang API change.
llvm-svn: 347673
2018-11-27 16:40:21 +00:00
Bruce Mitchener b8233f8c06 Add support for the Dylan language to ClangASTContext
Summary:
This change adds eLanguageTypeDylan to the set of languages supported
by ClangASTContext. Debug info generated by the Open Dylan compiler's
LLVM back-end was designed to be compatible with C debug info.

Patch by Peter Housel.

Reviewers: clayborg

Reviewed By: clayborg

Subscribers: brucem, lldb-commits, aprantl

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

llvm-svn: 347637
2018-11-27 05:37:27 +00:00
Gabor Marton b795ed9381 [ASTImporter] Set MustBuildLookupTable on PrimaryContext
Summary: SetMustBuildLookupTable() must always be called on a primary context.

Reviewers: labath, shafik, a.sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411

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

llvm-svn: 347575
2018-11-26 17:09:50 +00:00
Bill Wendling d7656dec98 Update call to EvaluateAsInt() to the new syntax.
llvm-svn: 347418
2018-11-21 20:44:38 +00:00
Nico Weber 1742ba5a2d Revert 347365, its prerequisite 347364 got reverted.
llvm-svn: 347391
2018-11-21 12:50:13 +00:00
Bill Wendling 8c8bdbe441 Update call to EvaluateAsInt() to the new syntax.
llvm-svn: 347365
2018-11-20 23:24:18 +00:00
Zachary Turner 95997f6110 Fix a use-after-free of the ABI plugin.
This was introduced in r346775.  Previously the ABI shared_ptr
was declared as a function local static meaning it would live
forever.  After the change, someone has to create a strong
reference to it or it will go away.  In this code, we were
calling ABI::FindPlugin(...).get(), so it was being immediately
destroyed and we were holding onto a dangling pointer.

llvm-svn: 346932
2018-11-15 05:06:59 +00:00
George Rimar 004bcb78ed [LLDB] - Recommit r346848 "[LLDB] - Support the single file split DWARF.".
Test cases were updated to not use the local compilation dir which
is different between development pc and build bots.

Original commit message:

[LLDB] - Support the single file split DWARF.

DWARF5 spec describes a single file split dwarf case
(when .dwo sections are in the .o files).

Problem is that LLDB does not work correctly in that case.
The issue is that, for example, both .debug_info and .debug_info.dwo
has the same type: eSectionTypeDWARFDebugInfo. And when code searches
section by type it might find the regular debug section
and not the .dwo one.

The patch fixes that. With it, LLDB is able to work with
output compiled with -gsplit-dwarf=single flag correctly.

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

llvm-svn: 346855
2018-11-14 13:01:15 +00:00
George Rimar 7cdb22b1ef Revert r346848 "[LLDB] - Support the single file split DWARF."
It broke BB:
http://green.lab.llvm.org/green/job/lldb-cmake/12522/testReport/junit/LLDB/Breakpoint/single_file_split_dwarf_test/

llvm-svn: 346853
2018-11-14 12:04:31 +00:00
George Rimar 98963db57d [LLDB] - Support the single file split DWARF.
DWARF5 spec describes a single file split dwarf case
(when .dwo sections are in the .o files).

Problem is that LLDB does not work correctly in that case.
The issue is that, for example, both .debug_info and .debug_info.dwo
has the same type: eSectionTypeDWARFDebugInfo. And when code searches
section by type it might find the regular debug section
and not the .dwo one.

The patch fixes that. With it, LLDB is able to work with
output compiled with -gsplit-dwarf=single flag correctly.

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

llvm-svn: 346848
2018-11-14 10:35:14 +00:00
Jonas Devlieghere 87e403aa4f Re-land "Extract construction of DataBufferLLVM into FileSystem"
This fixes some UB in isLocal detected by the sanitized bot.

llvm-svn: 346707
2018-11-12 21:24:50 +00:00
Davide Italiano 9a89d93d62 Revert "Extract construction of DataBufferLLVM into FileSystem"
It broke the lldb sanitizer bots.

llvm-svn: 346694
2018-11-12 19:08:19 +00:00
Aleksandr Urakov 1dc51db757 [ClangASTContext] Extract VTable pointers from C++ objects
This patch processes the case of retrieving a virtual base when the object is
already read from the debuggee memory.

To achieve that ValueObject::GetCPPVTableAddress was removed and was
reimplemented in ClangASTContext (because access to the process is needed to
retrieve the VTable pointer in general, and because this is the only place that
used old version of ValueObject::GetCPPVTableAddress).

This patch allows to use real object's VTable instead of searching virtual bases
by offsets restored by MicrosoftRecordLayoutBuilder. PDB has no enough info to
restore VBase offsets properly, so we have to read real VTable instead.

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

llvm-svn: 346669
2018-11-12 16:23:50 +00:00
Jonas Devlieghere ceff6644bb Remove header grouping comments.
This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.

llvm-svn: 346626
2018-11-11 23:17:06 +00:00
Jonas Devlieghere 1cc0714c68 Extract construction of DataBufferLLVM into FileSystem
This moves construction of data buffers into the FileSystem class. Like
some of the previous refactorings we don't translate the path yet
because the functionality hasn't been landed in LLVM yet.

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

llvm-svn: 346598
2018-11-10 22:44:06 +00:00
Jorge Gorbe Moya a6e6c18ade [lldb] Silence unhandled enums warning.
The warning was introduced by r346392, which introduces new builtin
types (to support cl_intel_device_side_avc_motion_estimation OpenCL
extension).

Note that this patch only inserts empty cases to silence the warning and
unblock our integrate, does not aim to add support for the new types in
lldb.

llvm-svn: 346441
2018-11-08 22:04:58 +00:00
Shafik Yaghmour 8c5ec1ff46 Refactor ClangASTContext::AddEnumerationValueToEnumerationType() to remove redundant parameter which can be calculated from other parameter.
rdar://problem/43822994

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

llvm-svn: 346428
2018-11-08 18:42:00 +00:00
Adrian Prantl eca07c592a Fix (and improve) the support for C99 variable length array types
Clang recently improved its DWARF support for C VLA types. The DWARF
now looks like this:

0x00000051:         DW_TAG_variable [4]
                     DW_AT_location( fbreg -32 )
                     DW_AT_name( "__vla_expr" )
                     DW_AT_type( {0x000000d3} ( long unsigned int ) )
                     DW_AT_artificial( true )
...
0x000000da:     DW_TAG_array_type [10] *
                 DW_AT_type( {0x000000cc} ( int ) )

0x000000df:         DW_TAG_subrange_type [11]
                     DW_AT_type( {0x000000e9} ( __ARRAY_SIZE_TYPE__ ) )
                     DW_AT_count( {0x00000051} )

Without this patch LLDB will naively interpret the DIE offset 0x51 as
the static size of the array, which is clearly wrong.  This patch
extends ValueObject::GetNumChildren to query the dynamic properties of
incomplete array types.

See the testcase for an example:

   4   int foo(int a) {
   5   	     int vla[a];
   6   	       for (int i = 0; i < a; ++i)
   7   	           vla[i] = i;
   8
-> 9            pause(); // break here
   10  		return vla[a-1];
   11   }

(lldb) fr v vla
(int []) vla = ([0] = 0, [1] = 1, [2] = 2, [3] = 3)
(lldb) quit

rdar://problem/21814005

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

llvm-svn: 346165
2018-11-05 20:49:07 +00:00
Jonas Devlieghere 454057da2a Remove OCaml debugger plugin
In January Davide sent an e-mail to the mailing list to suggest removing
unmaintained language plugins such as Go and Java. The plan was to have
some cool down period to allow users to speak up, however after that the
plugins were never actually removed.

This patch removes the OCaml debugger plugin.

The plugin can be added again in the future if it is mature enough both
in terms of testing and maintenance commitment.

Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html

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

llvm-svn: 346159
2018-11-05 19:34:03 +00:00
Jonas Devlieghere 0b8c5c9e13 Remove Java debugger plugin
In January Davide sent an e-mail to the mailing list to suggest removing
unmaintained language plugins such as Go and Java. The plan was to have
some cool down period to allow users to speak up, however after that the
plugins were never actually removed.

This patch removes the Java debugger plugin.

The plugin can be added again in the future if it is mature enough both
in terms of testing and maintenance commitment.

Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html

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

llvm-svn: 346158
2018-11-05 19:34:02 +00:00
Jonas Devlieghere 77198bc79b Remove Go debugger plugin
In January Davide sent an e-mail to the mailing list to suggest removing
unmaintained language plugins such as Go and Java. The plan was to have
some cool down period to allow users to speak up, however after that the
plugins were never actually removed.

This patch removes the Go debugger plugin.

The plugin can be added again in the future if it is mature enough both
in terms of testing and maintenance commitment.

Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2018-January/013171.html

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

llvm-svn: 346157
2018-11-05 19:33:59 +00:00
Zachary Turner 115209ece5 Properly cast from DeclContext to Decl.
Apparently there's a special procedure for doing this.  Not
following this silently breaks builds.

llvm-svn: 346156
2018-11-05 19:25:39 +00:00
Zachary Turner 4911023fe3 Add a target modules dump ast command.
This is useful for investigating the clang ast as you reconstruct
it via by parsing debug info.  It can also be used to write tests
against.

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

llvm-svn: 346149
2018-11-05 17:40:28 +00:00
Davide Italiano 407c6910d4 Revert "[Symbol] Search symbols with name and type in a symbol file"
It broke MacOS buildbots.

llvm-svn: 346045
2018-11-02 21:59:14 +00:00
Aleksandr Urakov 15da7684db [Symbol] Search symbols with name and type in a symbol file
Summary:
This patch adds possibility of searching a public symbol with name and type in a
symbol file. It is helpful when working with PE, because PE's symtabs contain
only imported / exported symbols only. Such a search is required for e.g.
evaluation of an expression that calls some function of the debuggee.

Reviewers: zturner, asmith, labath, clayborg, espindola

Reviewed By: clayborg

Subscribers: emaste, arichardson, aleksandr.urakov, jingham, lldb-commits, stella.stamenova

Tags: #lldb

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

llvm-svn: 345957
2018-11-02 08:54:35 +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 dbd7fabaa0 [FileSystem] Remove Exists() from FileSpec
This patch removes the Exists method from FileSpec and updates its uses
with calls to the FileSystem.

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

llvm-svn: 345854
2018-11-01 17:09:25 +00:00
Jonas Devlieghere 59b78bcba2 [FileSystem] Remove GetByteSize() from FileSpec
This patch removes the GetByteSize method from FileSpec and updates its
uses with calls to the FileSystem.

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

llvm-svn: 345812
2018-11-01 04:45:28 +00:00
Erik Pilkington fa98390b3c NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)
We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.

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

llvm-svn: 345637
2018-10-30 20:31:30 +00:00
Aleksandr Urakov 4538ed3b85 [x86] Fix issues with a realigned stack in MSVC compiled applications
Summary:
This patch fixes issues with a stack realignment.

MSVC maintains two frame pointers (`ebx` and `ebp`) for a realigned stack - one
is used for access to function parameters, while another is used for access to
locals. To support this the patch:
- adds an alternative frame pointer (`ebx`);
- considers stack realignment instructions (e.g. `and esp, -32`);
- along with CFA (Canonical Frame Address) which point to the position next to
  the saved return address (or to the first parameter on the stack) introduces
  AFA (Aligned Frame Address) which points to the position of the stack pointer
  right after realignment. AFA is used for access to registers saved after the
  realignment (see the test);

Here is an example of the code with the realignment:
```
struct __declspec(align(256)) OverAligned {
  char c;
};

void foo(int foo_arg) {
  OverAligned oa_foo = { 1 };
  auto aaa_foo = 1234;
}

void bar(int bar_arg) {
  OverAligned oa_bar = { 2 };
  auto aaa_bar = 5678;
  foo(1111);
}

int main() {
  bar(2222);
  return 0;
}
```
and here is the `bar` disassembly:
```
push    ebx
mov     ebx, esp
sub     esp, 8
and     esp, -100h
add     esp, 4
push    ebp
mov     ebp, [ebx+4]
mov     [esp+4], ebp
mov     ebp, esp
sub     esp, 200h
mov     byte ptr [ebp-200h], 2
mov     dword ptr [ebp-4], 5678
push    1111            ; foo_arg
call    j_?foo@@YAXH@Z  ; foo(int)
add     esp, 4
mov     esp, ebp
pop     ebp
mov     esp, ebx
pop     ebx
retn
```

Reviewers: labath, zturner, jasonmolenda, stella.stamenova

Reviewed By: jasonmolenda

Subscribers: abidh, lldb-commits

Tags: #lldb

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

llvm-svn: 345577
2018-10-30 10:07:08 +00:00
Zachary Turner 117b1fa19a Don't type-erase the FunctionNameType or TypeClass enums.
This is similar to D53597, but following up with 2 more enums.
After this, all flag enums should be strongly typed all the way
through to the symbol files plugins.

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

llvm-svn: 345314
2018-10-25 20:45:40 +00:00
Zachary Turner 991e44534a Don't type-erase the SymbolContextItem enumeration.
When we get the `resolve_scope` parameter from the SB API, it's a
`uint32_t`.  We then pass it through all of LLDB this way, as a uint32.
This is unfortunate, because it means the user of an API never actually
knows what they're dealing with.  We can call it something like
`resolve_scope` and have comments saying "this is a value from the
`SymbolContextItem` enumeration, but it makes more sense to just have it
actually *be* the correct type in the actual C++ type system to begin
with.  This way the person reading the code just knows what it is.

The reason to use integers instead of enumerations for flags is because
when you do bitwise operations on enumerations they get promoted to
integers, so it makes it tedious to constantly be casting them back
to the enumeration types, so I've introduced a macro to make this
happen magically.  By writing LLDB_MARK_AS_BITMASK_ENUM after defining
an enumeration, it will define overloaded operators so that the
returned type will be the original enum.  This should address all
the mechanical issues surrounding using rich enum types directly.

This way, we get a better debugger experience, and new users to
the codebase can get more easily acquainted with the codebase because
their IDE features can help them understand what the types mean.

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

llvm-svn: 345313
2018-10-25 20:45:19 +00:00
Zachary Turner 970f38ead6 [NFC] Refactor SetBaseClasses and DeleteBaseClasses.
We currently had a 2-step process where we had to call
SetBaseClassesForType and DeleteBaseClasses.  Every single caller
followed this exact 2-step process, and there was manual memory
management going on with raw pointers.  We can do better than this
by storing a vector of unique_ptrs and passing this around.
This makes for a cleaner API, and we only need to call one method
so there is no possibility of a user forgetting to call
DeleteBaseClassSpecifiers.

In addition to this, it also makes for a *simpler* API.  Part of
why I wanted to do this is because when I was implementing the native
PDB interface I had to spend some time understanding exactly what I
was deleting and why.  ClangAST has significant mental overhead
associated with it, and reducing the API surface can go along
way to making it simpler for people to understand.

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

llvm-svn: 345312
2018-10-25 20:44:56 +00:00
Zachary Turner a3e2ea1c4a Change two methods from const char* to StringRef [NFC].
llvm-svn: 345055
2018-10-23 17:22:02 +00:00
George Rimar e4dee2696e [LLDB] - Implement the support for the .debug_loclists section.
This implements the support for .debug_loclists section, which is
DWARF 5 version of .debug_loc.

Currently, clang is able to emit it with the use of D53365.

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

llvm-svn: 345016
2018-10-23 09:46:15 +00:00
Vedant Kumar 74533bd3b8 [DWARF] Use a function-local offset for AT_call_return_pc
Logs provided by @stella.stamenova indicate that on Linux, lldb adds a
spurious slide offset to the return PC it loads from AT_call_return_pc
attributes (see the list thread: "[PATCH] D50478: Add support for
artificial tail call frames").

This patch side-steps the issue by getting rid of the load address
calculation in lldb's CallEdge::GetReturnPCAddress.

The idea is to have the DWARF writer emit function-local offsets to the
instruction after a call. I.e. return-pc = label-after-call-insn -
function-entry. LLDB can simply add this offset to the base address of a
function to get the return PC.

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

llvm-svn: 344960
2018-10-22 21:44:21 +00:00
Jonas Devlieghere 4f78c4f67b [SymbolFile] Add the module lock where necessary and assert that we own it.
As discussed with Greg at the dev meeting, we need to ensure we have the
module lock in the SymbolFile. Usually the symbol file is accessed
through the symbol vendor which ensures that the necessary locks are
taken. However, there are a few methods that are accessed by the
expression parser and were lacking the lock.

This patch adds the locking where necessary and everywhere else asserts
that we actually already own the lock.

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

llvm-svn: 344945
2018-10-22 20:14:36 +00:00
George Rimar 6e357123ed [LLDB] - Add basic support for .debug_rnglists section (DWARF5)
This adds a basic support of the .debug_rnglists section.
Only the DW_RLE_start_length and DW_RLE_end_of_list entries are supported.

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

llvm-svn: 344119
2018-10-10 08:11:15 +00:00
Vedant Kumar 4b36f7911d Add support for artificial tail call frames
This patch teaches lldb to detect when there are missing frames in a
backtrace due to a sequence of tail calls, and to fill in the backtrace
with artificial tail call frames when this happens. This is only done
when the execution history can be determined from the call graph and
from the return PC addresses of calls on the stack. Ambiguous sequences
of tail calls (e.g anything involving tail calls and recursion) are
detected and ignored.

Depends on D49887.

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

llvm-svn: 343900
2018-10-05 23:23:15 +00:00
Aaron Smith e7dbb93360 [lldb] Start a new line for the next output if there are no symbols in the current symtab
Summary:
If there is no newline the "lldb" prompt could be on the wrong line. To reproduce the missing newline you can do 'image dump smytab' on any binary.

Previously

Symtab, file = D:\upstream\build\Debug\bin\clang-diff.exe, num_symbols = 0(lldb)

Now

Symtab, file = D:\upstream\build\Debug\bin\clang-diff.exe, num_symbols = 0
(lldb)

Reviewers: zturner, aleksandr.urakov, lldb-commits

Subscribers: abidh

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

llvm-svn: 343497
2018-10-01 17:08:51 +00:00
Aleksandr Urakov bc4707cc17 [PDB] Restore the calling convention from PDB
Summary:
This patch implements restoring of the calling convention from PDB.
It is necessary for expressions evaluation, if we want to call a function
of the debuggee process with a calling convention other than ccall.

Reviewers: clayborg, zturner, labath, asmith

Reviewed By: clayborg

Subscribers: teemperor, lldb-commits, stella.stamenova

Tags: #lldb

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

llvm-svn: 343084
2018-09-26 09:03:34 +00:00
George Rimar c6c7bfc4d2 [LLDB] - Improved DWARF5 support.
This patch improves the support of DWARF5.
Particularly the reporting of source code locations.

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

llvm-svn: 342153
2018-09-13 17:06:47 +00:00
Aleksandr Urakov 709426b33a [PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.

PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.

The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.

PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.

Reviewers: asmith, zturner, labath

Reviewed By: asmith

Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova

Tags: #lldb

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

llvm-svn: 341782
2018-09-10 08:08:43 +00:00
David Bolvansky aa75dd128c [Symtab][NFC] Added llvm_unreachable to supress compiler warning
Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Subscribers: lldb-commits

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

llvm-svn: 341315
2018-09-03 12:57:54 +00:00
Adrian Prantl 431b158400 Support setting a breakpoint by FileSpec+Line+Column in the SBAPI.
This patch extends the SBAPI to allow for setting a breakpoint not
only at a specific line, but also at a specific (minimum) column. When
a column is specified, it will try to find an exact match or the
closest match on the same line that comes after the specified
location.

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

llvm-svn: 341078
2018-08-30 15:11:00 +00:00
Frederic Riss 0d0a5960a5 Provide a default implementation of TypeSystem::GetNumTemplateArguments
... and remove the dummy implementations from the languages that do not
support it.

llvm-svn: 341006
2018-08-30 00:37:23 +00:00
Aleksandr Urakov ff70172716 [NFC] Minor update to comment
Update comment after rLLDB339994

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

llvm-svn: 340151
2018-08-20 05:59:27 +00:00
Aleksandr Urakov 534594822f Fix compiler warnings after rL339649.
Differential Revision: https://reviews.llvm.org/D49980

llvm-svn: 339994
2018-08-17 07:28:24 +00:00
Aleksandr Urakov 7d2a74fc54 [PDB] Parse UDT symbols and pointers to members (combined patch)
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
2018-08-14 07:57:44 +00:00
Raphael Isemann a7f19e5fda Use a DenseMap for looking up functions by UID in CompileUnit::FindFunctionByUID
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
2018-08-11 23:40:27 +00:00
Stefan Granitz f1a98df6ee Use rich mangling information in Symtab::InitNameIndexes()
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
2018-08-08 21:57:37 +00:00
Vedant Kumar 6504d4390f Delete a dead Function constructor (NFC)
llvm-svn: 339206
2018-08-07 23:48:40 +00:00
Raphael Isemann 12d74b911d Removed duplicated commented-out code [NFC]
llvm-svn: 339202
2018-08-07 23:24:24 +00:00