Commit Graph

22020 Commits

Author SHA1 Message Date
Djordje Todorovic 2bf44d11cb Revert "Reland "[DebugInfo] Enable the debug entry values feature by default""
This reverts commit rGa82d3e8a6e67.
2020-02-18 16:38:11 +01:00
Pavel Labath b807a28787 [lldb] Merge RangeArray and RangeVector
The two classes are equivalent, except:
- the former uses a llvm::SmallVector (with a configurable size), while
  the latter uses std::vector.
- the former has a typo in one of the functions name

This patch just leaves one class, using llvm::SmallVector, and defaults
the small size to zero. This is the same thing we did with the
RangeDataVector class in D56170.
2020-02-18 15:22:55 +01:00
Djordje Todorovic a82d3e8a6e Reland "[DebugInfo] Enable the debug entry values feature by default"
This patch enables the debug entry values feature.

  - Remove the (CC1) experimental -femit-debug-entry-values option
  - Enable it for x86, arm and aarch64 targets
  - Resolve the test failures
  - Leave the llc experimental option for targets that do not
    support the CallSiteInfo yet

Differential Revision: https://reviews.llvm.org/D73534
2020-02-18 14:41:08 +01:00
Raphael Isemann 40b2c7f29b [lldb] Fix another instance where we pass a nullptr as TypeSourceInfo to NonTypeTemplateParmDecl::Create
Summary:
Follow up to an issue pointed out in the review of D73808. We shouldn't just pass in a nullptr TypeSourceInfo
in case Clang decided to access it.

Reviewers: shafik, vsk

Reviewed By: shafik, vsk

Subscribers: kristof.beyls, JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73946
2020-02-18 13:25:31 +01:00
Tatyana Krasnukha db23825970 [lldb][test] Remove expected failure decorator from test_copy_from_dummy_target (TestScriptedResolver)
This test case doesn't check that breakpoint's locations are resolved, and it passes on Windows too.
2020-02-18 15:04:29 +03:00
Tatyana Krasnukha 7fb06796ab [lldb][NFC] Remove unused parameter
Rename search-filter's CopyForBreakpoint to CreateCopy, since they don't
do anything with breakpoints.
2020-02-18 13:49:08 +03:00
Tatyana Krasnukha b624b7dfd0 [lldb] Make shared_from_this-related code safer
Pass TargetSP to filters' CreateFromStructuredData, don't let them guess
whether target object is managed by a shared_ptr.

Make Breakpoint sure that m_target.shared_from_this() is safe by passing TargetSP
to all its static Create*** member-functions. This should be enough, since Breakpoint's
constructors are private/protected and never called directly (except by Target itself).
2020-02-18 13:49:07 +03:00
Tatyana Krasnukha 185ef697ef [lldb] Don't call CopyForBreakpoint from a Breakpoint's constructor
Some implementations (BreakpointResolverScripted) try calling the breakpoint's shared_from_this(),
that makes LLDB crash.
2020-02-18 13:49:07 +03:00
Raphael Isemann 3f0661b5e7 [lldb][NFC] Fix compilation of SymbolFilePDBTests.cpp after FindNamespace API change
Since f9568a9549 this function takes a
CompilerDeclContext reference instead of a pointer. It overlooked this function
when I fixed the compilation for FindTypes.
2020-02-18 11:25:12 +01:00
Raphael Isemann 51d8c59833 [lldb] Don't model std::atomic as a transparent data structure in the data formatter
Summary:
Currently the data formatter is treating `std::atomic` variables as transparent wrappers
around their underlying value type. This causes that when printing `std::atomic<A *>`, the data
formatter will forward all requests for the children of the atomic variable to the `A *` pointer type
which will then return the respective members of `A`. If `A` in turn has a member that contains
the original atomic variable, this causes LLDB to infinitely recurse when printing an object with
such a `std::atomic` pointer member.

We could implement a workaround similar to whatever we do for pointer values but this patch
just implements the `std::atomic` formatter in the same way as we already implement other
formatters (e.g. smart pointers or `std::optional`) that just model the contents of the  as a child
"Value". This way LLDB knows when it actually prints a pointer and can just use its normal
workaround if "Value" is a recursive pointer.

Fixes rdar://59189235

Reviewers: JDevlieghere, jingham, shafik

Reviewed By: shafik

Subscribers: shafik, christof, jfb, abidh, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D74310
2020-02-18 11:22:12 +01:00
Pavel Labath 00539d8b64 [lldb/DWARF] Support the debug_str_offsets section in dwp files
Summary:
In dwp files a constant (from the debug_cu_index section) needs to be
added to each reference into the debug_str_offsets section.

I've tried to implement this to roughly match the llvm flow: I've
changed the DWARFormValue to stop resolving the indirect string
references directly -- instead, it calls into DWARFUnit, which resolves
this for it (similar to how it already resolves indirect range and
location list references). I've also done a small refactor of the string
offset base computation code in DWARFUnit in order to make it easier to
access the debug_cu_index base offset.

Reviewers: JDevlieghere, aprantl, clayborg

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D74723
2020-02-18 11:02:34 +01:00
Raphael Isemann 7d13812329 [lldb] Fix compilation of SymbolFilePDBTests.cpp after FindTypes API change
Since f9568a9549 this function takes a
CompilerDeclContext reference instead of a pointer.
2020-02-18 10:52:02 +01:00
Pavel Labath 0863f67579 [lldb] Remove DataExtractor::GetPointer
This function is equivalent to GetAddress, but getAddress is also
present on the llvm version of the data extractor.
2020-02-18 10:38:41 +01:00
Raphael Isemann f14680ce29 [lldb][NFC] Documention that OptionDefinition::completion_type contains enum values
This should be just the enum type but that's a larger refactoring, so document that
this is not just an integer until we can make this just the type of the enum.
2020-02-18 10:33:38 +01:00
Pavel Labath 0ba247bc21 [lldb] Remove the mutable specifier from DataExtractor's member
Having m_data_sp mutable sounds like a very bad idea. Fortunately,
nothing relies on this possibility.
2020-02-18 10:26:43 +01:00
Raphael Isemann 57835875bd [lldb][NFC] Modernize documentation in lldb-private-types.h 2020-02-18 10:25:27 +01:00
Raphael Isemann 8ffea27ae4 [lldb] Refactor and test TypeSystemClang::GetEnumerationIntegerType 2020-02-18 09:52:49 +01:00
Raphael Isemann 813ca53fde [lldb][NFC] Document TypeSystemClang 2020-02-18 09:00:03 +01:00
Raphael Isemann f9568a9549 [lldb][NFC] Make all CompilerDeclContext parameters references instead of pointers
Summary:
All of our lookup APIs either use `CompilerDeclContext &` or `CompilerDeclContext *` semi-randomly it seems.
This leads to us constantly converting between those two types (and doing nullptr checks when going from
pointer to reference). It also leads to the confusing situation where we have two possible ways to express
that we don't have a CompilerDeclContex: either a nullptr or an invalid CompilerDeclContext (aka a default
constructed CompilerDeclContext).

This moves all APIs to use references and gets rid of all the nullptr checks and conversions.

Reviewers: labath, mib, shafik

Reviewed By: labath, shafik

Subscribers: shafik, arphaman, abidh, JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D74607
2020-02-18 08:58:36 +01:00
Jonas Devlieghere ffd78a008a [lldb] Replace #pragma once with header guard
This got messed up when updating the header guard. Remove the
`pragma once` and use a header guard instead.
2020-02-17 23:39:19 -08:00
Jonas Devlieghere cdc514e4c6 [lldb] Update header guards to be consistent and compliant with LLVM (NFC)
LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.

Differential revision: https://reviews.llvm.org/D74743
2020-02-17 23:15:40 -08:00
Jonas Devlieghere 866b7a6519 [lldb] Replace empty ctor en dtor bodies with =default (NFC)
Use = default instead of empty constructor and destructor bodies in the
API layer.
2020-02-17 22:58:26 -08:00
Jonas Devlieghere aa2ae6af81 [lldb/Plugins] Add missing initialize/terminate calls
Add missing initialize and terminate calls for DynamicLoaderHexagonDYLD
and ObjectFileJIT.
2020-02-17 21:28:16 -08:00
Jonas Devlieghere b0cb98b1f5 [lldb/Plugins] Conditionally build OperatingSystemPython.
Only build the Python Operating System Plugin when LLDB_ENABLE_PYTHON is
set to true.
2020-02-17 21:22:37 -08:00
Muhammad Omair Javaid fdc122e4ed Revert "[lldb/lldb-server] Add target.xml support for qXfer request."
This patch cause floating point registers to fail on LLDB aarch64-linux
buildbot.

http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/1713

This reverts commit aedc196101.
2020-02-18 10:16:52 +05:00
Jonas Devlieghere ccad194861 [lldb/Plugins] Rename initializers to match their plugin name.
Use LLDB_PLUGIN_DEFINE_ADV to make the name of the generated initializer
match the name of the plugin. This is a step towards generating the
initializers with a def file. I'm landing this change in pieces so I can
narrow down what exactly breaks the Windows bot.
2020-02-17 20:07:53 -08:00
Jonas Devlieghere bcde387f46 [lldb/Plugins] Initialize all ABI plugins by their plugin name 2020-02-17 19:55:43 -08:00
Jonas Devlieghere ac1ea0d3da [lldb/Plugins] Remove PLUGIN from libraries that aren't really plugins.
Although their name and location suggests otherwise, these libraries are
not really plugins but rather support the real plugins.
2020-02-17 19:40:00 -08:00
Jonas Devlieghere 478c9cc4f5 [lldb/Plugins] Rename lldbPluginDisassemblerLLVM (NFC) 2020-02-17 19:14:01 -08:00
Jonas Devlieghere 50c9cd9526 Revert "[lldb/CMake] Auto-generate the Initialize and Terminate calls for plugin"
This is still failing spectacularly on the Windows bot and I still have
no clue what's going on.
2020-02-17 19:04:50 -08:00
Jonas Devlieghere fcae62167e [lldb/Plugin] Unconditionally build Darwin-Kernel 2020-02-17 18:14:24 -08:00
Jonas Devlieghere c8001d56df [lldb/Plugin] Fix some issues on Windows
- Don't initialize NativePDB.
 - Initialize ProcessWindows after any Process*Core plugins.
 - Don't initialize DynamicLoaderDarwinKernel on non-Darwin platforms.
2020-02-17 17:22:18 -08:00
Jonas Devlieghere 9b12dc98fd Re-land "[lldb/CMake] Auto-generate the Initialize and Terminate calls for plugin"
This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.

The previously landed patch got reverted because it was lacking:

 (1) A plugin definition for the Objective-C language runtime,
 (2) The dependency between the Static and WASM dynamic loader,
 (3) Explicit initialization of ScriptInterpreterNone for lldb-test.

All issues have been addressed in this patch.

Differential revision: https://reviews.llvm.org/D73067
2020-02-17 14:43:05 -08:00
Jonas Devlieghere 46c4f63ec4 [lldb/Plugin] Update ProcessWindows plugin for revert 2020-02-17 13:53:07 -08:00
Jonas Devlieghere 058cb1b47f Revert "[lldb/CMake] Auto-generate the Initialize and Terminate calls for plugin"
This temporarily reverts commit 7d6da329de
because it's causing test failures on the bots.
2020-02-17 12:34:21 -08:00
Jonas Devlieghere deaa6916d3 [lldb/Plugin] Remove PLUGIN from Process POSIX & Linux
ProcessPOSIX and ProcessLinux are not real plugins and should not be
marked as such. This should fix the Linux bots.
2020-02-17 11:20:51 -08:00
Jonas Devlieghere 3431dc32a4 [lldb/Plugin] Fix plugin definition for ProcessWindows
This should fix the unresolved external symbol error.
2020-02-17 10:24:18 -08:00
Jonas Devlieghere 7d6da329de [lldb/CMake] Auto-generate the Initialize and Terminate calls for plugin
This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.

Differential revision: https://reviews.llvm.org/D73067
2020-02-17 09:07:00 -08:00
Jonas Devlieghere 8f95a82bc0 [lldb] Fix Windows bot.
Should fix error C2039: 'toupper': is not a member of 'std'.
2020-02-17 09:06:59 -08:00
Jan Kratochvil 2178088879 Separate DIERef vs. user_id_t: m_function_scope_qualified_name_map
As discussed in https://reviews.llvm.org/D73206#1871895 there is both
`DIERef` and `user_id_t` and sometimes (for DWZ) we need to encode Main
CU into them and sometimes we cannot as it is unavailable at that point
and at the same time not even needed.

I have also noticed `DIERef` and `user_id_t` in fact contain the same
information which can be seen in SymbolFileDWARF::GetUID.

SB* API/ABI is already using `user_id_t` and it needs to encode Main CU
for DWZ. Therefore what about making `DIERef` the identifier not
containing Main CU and `user_id_t` the identifier containing Main CU?

It is sort of a revert of D63322.

I find this patch as a NFC cleanup to the codebase - to satisfy a new
premise `user_id_t` is used as little as possible and thus only for
external interfaces which must not deal with MainCU in any way.

Its larger goal is to satisfy a plan to implement DWZ support.

Differential Revision: https://reviews.llvm.org/D74637
2020-02-17 16:35:42 +01:00
Pavel Labath b2d64b698f [lldb] Fix build error from 07355c1c08
The error is: no matching function for call to 'transform(std::string&, std::__cxx11::basic_string<char>::iterator, <unresolved overloaded function type>)'

The fix: replace llvm::transform with an equally simple hand-rolled
loop.
2020-02-17 14:12:29 +01:00
Pavel Labath 67f63f3f7c [lldb/DWARF] Re-enable basic dwp support
Summary:
This patch removes the bitrotted SymbolFileDWARF(Dwo)Dwp classes, and
replaces them with dwp support implemented directly inside
SymbolFileDWARFDwo, in a manner mirroring the implementation in llvm.
This patch does:
- add support for the .debug_cu_index section to our DWARFContext
- adds a llvm::DWARFUnitIndex argument to the DWARFUnit constructors.
  This argument is used to look up the offsets of the debug_info and
  debug_abbrev contributions in the sections of the dwp file.
- makes sure the creation of the DebugInfo object as well as the initial
  discovery of DWARFUnits is thread-safe, as we can now call this
  concurrently when doing parallel indexing.

This patch does not:
- use the DWARFUnitIndex to search for other kinds of contributions
  (debug_loc, debug_ranges, etc.). This means that units which reference
  these sections will not work correctly. These will be handled by
  follow-up patches, but even the present level of support is sufficient
  to enable basic functionality.
- Make the llvm::DWARFContext thread-safe. Right now, it just avoids this
  problem by ensuring everything is initialized ahead of time. However,
  this is something we will run into more often as we try to use more of
  llvm, and so I plan to start looking into our options here.

Reviewers: JDevlieghere, aprantl, clayborg

Subscribers: mgorny, mgrang, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D73783
2020-02-17 14:10:36 +01:00
Pavel Labath 07355c1c08 [lldb] Delete register info definitions in the x86_64 ABI classes
Summary:
These definitions are used to "augment" information received from the remote
target with eh/debug frame and "generic" register numbers.

Besides being verbose, this information was also incomplete (new registers like
xmm16-31 were missing) and sometimes even downright wrong (ymm register
numbers).

Most of this information is available via llvm's MCRegisterInfo. This patch
creates a new class, MCBasedABI, which retrieves the eh and debug frame register
numbers this way. The tricky part here is that the llvm class uses all-caps
register names, whereas lldb register are lowercase, and sometimes called
slightly differently. Therefore this class introduces some hooks to allow a
subclass to customize the MC lookup. The subclass also needs to suply the
"generic" register numbers, as this is an lldb invention.

This patch ports the x86_64 ABI classes to use the new register info mechanism.
It also creates a new "ABIx86_64" class which can be used to house code common
to x86_64 both ABIs. Right now, this just consists of a single function, but
there are plenty of other things that could be moved here too.

Reviewers: JDevlieghere, jasonmolenda

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D74244
2020-02-17 14:01:36 +01:00
Martin Storsjö 0e1da1ef4a [LLDB] Fix GCC warnings about extra semicolons. NFC. 2020-02-17 14:16:46 +02:00
Pavel Labath d41d528648 [lldb] Add @skipIfXmlSupportMissing to TestWasm.py
These tests rely on being able to parse qXfer:libraries:read packet
(which is in xml).
2020-02-17 13:12:52 +01:00
Paolo Severini c1121908aa [LLDB] Add DynamicLoaderWasmDYLD plugin for WebAssembly debugging
Add a dynamic loader plug-in class for WebAssembly modules.

Differential Revision: https://reviews.llvm.org/D72751
2020-02-17 12:42:23 +01:00
Levon Ter-Grigoryan aedc196101 [lldb/lldb-server] Add target.xml support for qXfer request.
Summary:
Synthesize target.xml in lldb-server to avoid a long chain of
qRegisterInfo packets, which can be slow over low-latency links.

Reviewers: jarin, labath

Reviewed By: labath

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D74217
2020-02-17 12:05:28 +01:00
Jan Kratochvil 516ba158b6 [lldb] [nfc] Simplify user_id_t -> size_t
As discussed in https://reviews.llvm.org/D73206#1871895> simplifying
usage of `user_id_t`.

There is even written:
  // The compile unit ID is the index of the DWARF unit.
  DWARFUnit *dwarf_cu = info->GetUnitAtIndex(comp_unit->GetID());

Differential Revision: https://reviews.llvm.org/D74670
2020-02-17 10:24:19 +01:00
Raphael Isemann cfb29e4a54 [lldb] Fix some tests failing with gmodules after change to stdlib.h
Commit 82b47b2978 changes the way the stdlib.h
header is structured which seems to cause strange lookup failures in the modules
build. This updates a few failing tests so that they pass with the new
behavior of stdlib.h.

See the discussion in https://reviews.llvm.org/rG82b47b2978405f802a33b00d046e6f18ef6a47be
2020-02-17 09:39:09 +01:00
Jason Molenda 83bea6d99d Remove 'process launch failed:' message prefix in Target::Launch
SB API clients can describe the failure message in a more natural
way for their UI, this doesn't add information for them.

Differential Revision: https://reviews.llvm.org/D74585
<rdar://problem/49953304>
2020-02-14 18:42:38 -08:00