Commit Graph

1527 Commits

Author SHA1 Message Date
Alexander Mols 0a2d4f3f24 [lldb] Enable Rust v0 symbol demangling
Rust's v0 name mangling scheme [1] is easy to disambiguate from other
name mangling schemes because symbols always start with `_R`. The llvm
Demangle library supports demangling the Rust v0 scheme. Use it to
demangle Rust symbols.

Added unit tests that check simple symbols. Ran LLDB built with this
patch to debug some Rust programs compiled with the v0 name mangling
scheme. Confirmed symbol names were demangled as expected.

Note: enabling the new name mangling scheme requires a nightly
toolchain:

```
$ cat main.rs
fn main() {
    println!("Hello world!");
}
$ $(rustup which --toolchain nightly rustc) -Z symbol-mangling-version=v0 main.rs -g
$ /home/asm/hacking/llvm/build/bin/lldb ./main --one-line 'b main.rs:2'
(lldb) target create "./main"
Current executable set to '/home/asm/hacking/llvm/rust/main' (x86_64).
(lldb) b main.rs:2
Breakpoint 1: where = main`main::main + 4 at main.rs:2:5, address = 0x00000000000076a4
(lldb) r
Process 948449 launched: '/home/asm/hacking/llvm/rust/main' (x86_64)
warning: (x86_64) /lib64/libgcc_s.so.1 No LZMA support found for reading .gnu_debugdata section
Process 948449 stopped
* thread #1, name = 'main', stop reason = breakpoint 1.1
    frame #0: 0x000055555555b6a4 main`main::main at main.rs:2:5
   1    fn main() {
-> 2        println!("Hello world!");
   3    }
(lldb) bt
error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
* thread #1, name = 'main', stop reason = breakpoint 1.1
  * frame #0: 0x000055555555b6a4 main`main::main at main.rs:2:5
    frame #1: 0x000055555555b78b main`<fn() as core::ops::function::FnOnce<()>>::call_once((null)=(main`main::main at main.rs:1), (null)=<unavailable>) at function.rs:227:5
    frame #2: 0x000055555555b66e main`std::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>(f=(main`main::main at main.rs:1)) at backtrace.rs:125:18
    frame #3: 0x000055555555b851 main`std::rt::lang_start::<()>::{closure#0} at rt.rs:49:18
    frame #4: 0x000055555556c9f9 main`std::rt::lang_start_internal::hc51399759a90501a [inlined] core::ops::function::impls::_$LT$impl$u20$core..ops..function..FnOnce$LT$A$GT$$u20$for$u20$$RF$F$GT$::call_once::h04259e4a34d07c2f at function.rs:259:13
    frame #5: 0x000055555556c9f2 main`std::rt::lang_start_internal::hc51399759a90501a [inlined] std::panicking::try::do_call::hb8da45704d5cfbbf at panicking.rs:401:40
    frame #6: 0x000055555556c9f2 main`std::rt::lang_start_internal::hc51399759a90501a [inlined] std::panicking::try::h4beadc19a78fec52 at panicking.rs:365:19
    frame #7: 0x000055555556c9f2 main`std::rt::lang_start_internal::hc51399759a90501a [inlined] std::panic::catch_unwind::hc58016cd36ba81a4 at panic.rs:433:14
    frame #8: 0x000055555556c9f2 main`std::rt::lang_start_internal::hc51399759a90501a at rt.rs:34:21
    frame #9: 0x000055555555b830 main`std::rt::lang_start::<()>(main=(main`main::main at main.rs:1), argc=1, argv=0x00007fffffffcb18) at rt.rs:48:5
    frame #10: 0x000055555555b6fc main`main + 28
    frame #11: 0x00007ffff73f2493 libc.so.6`__libc_start_main + 243
    frame #12: 0x000055555555b59e main`_start + 46
(lldb)
```

[1]: https://github.com/rust-lang/rust/issues/60705

Reviewed By: clayborg, teemperor

Differential Revision: https://reviews.llvm.org/D104054
2021-06-21 18:20:15 +02:00
Jonas Devlieghere 9494c510af [lldb] Use C++11 default member initializers
This converts a default constructor's member initializers into C++11
default member initializers. This patch was automatically generated with
clang-tidy and the modernize-use-default-member-init check.

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix

This is a mass-refactoring patch and this commit will be added to
.git-blame-ignore-revs.

Differential revision: https://reviews.llvm.org/D103483
2021-06-09 09:43:13 -07:00
Alex Langford 64576a1be8 [lldb][NFC] Refactor name to index maps in Symtab
The various maps in Symtab lead to some repetative code. This should
improve the situation somewhat.

Differential Revision: https://reviews.llvm.org/D103652
2021-06-08 12:36:54 -07:00
Greg Clayton b0572abf72 Improve performance when parsing symbol tables in mach-o files.
Some larger projects were loading quite slowly with the current LLDB on macOS and macOS simulator builds. I did some instrument traces and found 3 main culprits:
- a LLDB timer that was put into a function that was called too often
- a std::set that was keeping track of the address of symbols that were already added
- a unnamed function generator in ObjectFile that was going slow due to allocations

In order to see this in action I ran the latest LLDB on a large application with many frameworks using the following method:

(lldb) script import time; start_time = time.perf_counter()
(lldb) file Large.app
(lldb) script print(time.perf_counter() - start_time)

I first range "sudo purge" to clear the system file caches to simulate a cold startup of the debugger, followed by two iterations with warm file caches.

Prior to this fix I was seeing the following timings:

17.68 (cold)
14.56 (warm 1)
14.52 (warm 2)

After this fix I was seeing:

11.32 (cold)
8.43 (warm 1)
8.49 (warm 2)

Differential Revision: https://reviews.llvm.org/D103504
2021-06-02 10:31:37 -07:00
Raphael Isemann 76e47d4887 [lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.

Reviewed By: shafik

Differential Revision: https://reviews.llvm.org/D103084
2021-05-26 12:46:12 +02:00
Augusto Noronha ec28e43e01 Add null-pointer checks when accessing a TypeSystem's SymbolFile
A type system is not guaranteed to have a symbol file. This patch adds null-pointer checks so we don't crash when trying to access a type system's symbol file.

Reviewed By: aprantl, teemperor

Differential Revision: https://reviews.llvm.org/D101539
2021-05-11 13:15:20 -03:00
Med Ismail Bennani 35ecfda01c [lldb/Symbol] Fix column breakpoint `move_to_nearest_code` match
This patch fixes the column symbol resolution when creating a breakpoint
with the `move_to_nearest_code` flag set.

In order to achieve this, the patch adds column information handling in
the `LineTable`'s `LineEntry` finder. After experimenting a little, it
turns out the most natural approach in case of an inaccurate column match,
is to move backward and match the previous `LineEntry` rather than going
forward like we do with simple line breakpoints.

The patch also reflows the function to reduce code duplication.

Finally, it updates the `BreakpointResolver` heuristic to align it with
the `LineTable` method.

rdar://73218201

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-05-05 05:07:50 +00:00
Med Ismail Bennani 3e2ed74405 [lldb] Refactor argument group by SourceLocationSpec (NFCI)
This patch refactors a good part of the code base turning the usual
FileSpec, Line, Column, CheckInlines, ExactMatch arguments into a
SourceLocationSpec object.

This change is required for a following patch that will add handling of the
column line information when doing symbol resolution.

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-05-04 23:04:31 +00:00
Med Ismail Bennani 1435f6b00b [lldb] Move and clean-up the Declaration class (NFC)
This patch moves the Declaration class from the Symbol library to the
Core library. This will allow to use it in a more generic fashion and
aims to lower the dependency cycles when it comes to the linking.

The patch also does some cleaning up by making column information
permanent and removing the LLDB_ENABLE_DECLARATION_COLUMNS directives.

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-05-04 16:34:44 +00:00
Jason Molenda e9fe788d32 Target::ReadMemory read from read-only binary file Section, not memory
Commiting this patch for Augusto Noronha who is getting set
up still.

This patch changes Target::ReadMemory so the default behavior
when a read is in a Section that is read-only is to fetch the
data from the local binary image, instead of reading it from
memory.  Update all callers to use their old preferences
(the old prefer_file_cache bool) using the new API; we should
revisit these calls and see if they really intend to read
live memory, or if reading from a read-only Section would be
equivalent and important for performance-sensitive cases.

rdar://30634422

Differential revision: https://reviews.llvm.org/D100338
2021-04-16 16:13:07 -07:00
Greg Clayton 2d733923b8 Fix "image lookup --address" Summary results for inline functions.
Inline callstacks were being incorrectly displayed in the results of "image lookup --address". The deepest frame wasn't displaying the line table line entry, it was always showing the inline information's call file and line on the previous frame. This is now fixed and has tests to make sure it doesn't regress.

Differential Revision: https://reviews.llvm.org/D98761
2021-04-01 11:36:26 -07:00
Kim-Anh Tran 68dafe40a6 [lldb] Use CompileUnit::ResolveSymbolContext in SymbolFileDWARF
SymbolFileDWARF::ResolveSymbolContext is currently unaware that in DWARF5 the primary file is specified at file index 0. As a result it misses to correctly resolve the symbol context for the primary file when DWARF5 debug data is used and the primary file is only specified at index 0.

This change makes use of CompileUnit::ResolveSymbolContext to resolve the symbol context. The ResolveSymbolContext in CompileUnit has been previously already updated to reflect changes in DWARF5
and contains a more readable version. It can resolve more, but will also do a bit more work than
SymbolFileDWARF::ResolveSymbolContext (getting the Module, and going through SymbolFileDWARF::ResolveSymbolContextForAddress), however, it's mostly directed by $resolve_scope
what will be resolved, and ensures that code is easier to maintain if there's only one path.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D98619
2021-03-22 08:44:16 +01:00
Raphael Isemann 03310c1e95 [lldb][NFC] Give CompilerType's IsArrayType/IsVectorType/IsBlockPointerType out-parameters default values
We already do this for most functions that have out-parameters, so let's do
the same here and avoid all the `nullptr, nullptr, nullptr` in every call.
2021-02-23 11:15:31 +01:00
Jason Molenda fcdef15d77 Add a new Row setting to mark all un-declared regs as Undefined
Add a new state for UnwindPlan::Row which indicates that any
register not listed is not defined, and should not be found in
stack frames newer than this one and passed up the stack.  Mostly
intended for use with architectural default unwind plans that are
used for jitted stack frames, where we have no unwind information
or start address.  lldb has no way to tell if registers were
spilled in the jitted frame & overwritten, so passing register
values up the stack is not safe to show the user.

Architectural default unwind plans are also used as a fast unwind
plan on x86_64 in particular, and are used as the fallback unwind
plans when lldb thinks it may be able to work around a problem
which causes the unwinder to stop walking the stack early.

For fast unwind plans, when we don't find a register location in
the arch default unwind plan, we fall back to computing & using
the full unwind plan. One small part of this patch is to know that
a register marked as Undefined in the fast unwind plan is a special
case, and we should continue on to the full unwind plan to find what
the real unwind rule is for this register.

Differential Revision: https://reviews.llvm.org/D96829
<rdar://problem/70398009>
2021-02-17 23:52:28 -08:00
Jonas Devlieghere d97e9f1a3d [lldb] Simplify ObjectFile::FindPlugin (NFC)
Use early return to reduce the levels of indentation. Extract logic to
find object in container into helper function.
2020-12-23 14:06:40 -08:00
Andy Yankovsky 1432ae57bf [lldb] Add SBType::GetEnumerationIntegerType method
Add a method for getting the enumeration underlying type.

Differential revision: https://reviews.llvm.org/D93696
2020-12-22 10:08:22 -08:00
Andy Yankovsky e17a00fc87 [lldb] Add SBType::IsScopedEnumerationType method
Add a method to check if the type is a scoped enumeration (i.e. "enum
class/struct").

Differential revision: https://reviews.llvm.org/D93690
2020-12-22 10:08:21 -08:00
Jonas Devlieghere 5c1c8443eb [lldb] Abstract scoped timer logic behind LLDB_SCOPED_TIMER (NFC)
This patch introduces a LLDB_SCOPED_TIMER macro to hide the needlessly
repetitive creation of scoped timers in LLDB. It's similar to the
LLDB_LOG(F) macro.

Differential revision: https://reviews.llvm.org/D93663
2020-12-22 09:10:27 -08:00
Jason Molenda 2cedc44a92 Ignore DBGArchitecture from dsymForUUID's plist
When the architecture from the returned plist differs from the
architecture lldb will pick when loading the binary file, lldb will
reject the binary as not matching.  We are working with UUID's in
this case, so an architecture is not disambiguating anything; it
just opens this possibility for failing to load the specified binary.
Stop reading the architecture from the plist.

<rdar://problem/71612561>
Differential revision: https://reviews.llvm.org/D92692
2020-12-09 14:19:55 -08:00
Dave Lee 012fd0b17f [lldb] Remove unused IsFunctionType is_variadic_ptr parameter (NFC)
`is_variadic_ptr` is unused.

Differential Revision: https://reviews.llvm.org/D92778
2020-12-08 23:51:07 -08:00
Nathan Lanza 33c79f76af Revert "[lldb] add a missing dependency on intrinsics_gen"
This reverts commit 137ff73317.

This belongs in Apple's Swift fork since this is a direct fix for
unified Swift + llvm + lldb builds.
2020-11-20 16:02:16 -05:00
Stefan Gränitz 203b4774b8 [lldb][ObjectFile] Relocate sections for in-memory objects (e.g. received via JITLoaderGDB)
Part 2 of a fix for JITed code debugging. This has been a regression from 5.0 to 6.0 and it's still reproducible on current master: https://bugs.llvm.org/show_bug.cgi?id=36209 Part 1 was D61611 a while ago.

The in-memory object files we obtain from JITLoaderGDB are not yet relocated. It looks like this used to happen on the LLDB side and my guess is that it broke with D38142. (However, it's hard to tell because the whole thing was broken already due to the bug in part 1.) The patch moved relocation resolution to a later point in time and didn't apply it to in-memory objects. I am not aware of any reason why we wouldn't resolve relocations per-se, so I made it unconditional here. On Debian, it fixes the bug for me and all tests in `check-lldb` are still fine.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D90769
2020-11-10 11:37:53 +01:00
Richard Howell 137ff73317 [lldb] add a missing dependency on intrinsics_gen
Sometimes builds will fail with errors like:

```
In file included from /build/external/llvm-project/lldb/source/Symbol/SwiftASTContext.cpp:52:
In file included from /build/external/swift/include/swift/IRGen/Linking.h:22:
In file included from /build/external/swift/include/swift/SIL/SILFunction.h:24:
In file included from /build/external/swift/include/swift/SIL/SILBasicBlock.h:23:
In file included from /build/external/swift/include/swift/SIL/SILInstruction.h:21:
In file included from /build/external/swift/include/swift/AST/Builtins.h:24:
**/build/external/llvm-project/llvm/include/llvm/IR/Attributes.h:74:14: fatal error: 'llvm/IR/Attributes.inc' file not found**
**^~~~~~~~~~~~~~~~~~~~~~~~**
```
This change ensures the `Attributes.inc` file is generated before building `SwiftASTContext.cpp`.

Differential Revision: https://reviews.llvm.org/D90857
2020-11-06 13:15:08 -05:00
Walter Erquinigo cfd96f057b [trace][intel-pt] Implement the basic decoding functionality
Depends on D89408.

This diff finally implements trace decoding!

The current interface is

  $ trace load /path/to/trace/session/file.json
  $ thread trace dump instructions

  thread #1: tid = 3842849, total instructions = 22
    [ 0] 0x40052d
    [ 1] 0x40052d
    ...
    [19] 0x400521

  $ # simply enter, which is a repeat command
    [20] 0x40052d
    [21] 0x400529
    ...

This doesn't do any disassembly, which will be done in the next diff.

Changes:
- Added an IntelPTDecoder class, that is a wrapper for libipt, which is the actual library that performs the decoding.
- Added TraceThreadDecoder class that decodes traces and memoizes the result to avoid repeating the decoding step.
- Added a DecodedThread class, which represents the output from decoding and that for the time being only stores the list of reconstructed instructions. Later it'll contain the function call hierarchy, which will enable reconstructing backtraces.
- Added basic APIs for accessing the trace in Trace.h:
  - GetInstructionCount, which counts the number of instructions traced for a given thread
  - IsTraceFailed, which returns an Error if decoding a thread failed
  - ForEachInstruction, which iterates on the instructions traced for a given thread, concealing the internal storage of threads, as plug-ins can decide to generate the instructions on the fly or to store them all in a vector, like I do.
- DumpTraceInstructions was updated to print the instructions or show an error message if decoding was impossible.
- Tests included

Differential Revision: https://reviews.llvm.org/D89283
2020-11-05 18:38:03 -08:00
Ilya Bukonkin 2c0cbc47ca GetModule, GetExeModule methods added 2020-10-29 23:44:51 +03:00
David Blaikie 0b05732045 fix lldb for recent libDebugInfoDWARF API change 2020-10-23 19:20:38 -07:00
Jonas Devlieghere a4459feca4 [lldb] Fix use of undefined type 'lldb_private::UtilityFunction'
We were returning the default constructed unique_pointer from
TypeSystem.h for which the compiler does not have a definition. Move the
implementation into the cpp file.
2020-10-23 11:48:11 -07:00
Jason Molenda af5504edd6 Increase timeout to find a dSYM in macos DownloadObjectAndSymbolFile
With a large dSYM over a slow home connection, the two minute timeout
would sometimes be exceeded, and we haven't seen instances of a
long timeout causing people any problems, so we're bumping it up.

640 seconds ought to be enough for anyone.

<rdar://problem/67759526>
2020-10-15 00:57:23 -07:00
Adrian Prantl 9b1c06c0e8 Move initialization of Variable::m_loc_is_const_data into constructor (NFC)
This makes it symmetric with all other flags and makes it easier to
not forget to initialize it.

https://reviews.llvm.org/D89351
2020-10-13 17:01:28 -07:00
Pavel Labath 0610a25a85 [lldb] Delete copy operations on PluginInterface class
This is a polymorphic class, copying it is a bad idea.

This was not a problem because most classes inheriting from it were
deleting their copy operations themselves. However, this enables us to
delete those explicit deletions, and ensure noone forgets to add them in
the future.
2020-10-09 10:37:09 +02:00
Jim Ingham 1b1d981598 Revert "Revert "Add the ability to write target stop-hooks using the ScriptInterpreter.""
This reverts commit f775fe5964.

I fixed a return type error in the original patch that was causing a test failure.
Also added a REQUIRES: python to the shell test so we'll skip this for
people who build lldb w/o Python.
Also added another test for the error printing.
2020-09-29 12:01:14 -07:00
Jonas Devlieghere f775fe5964 Revert "Add the ability to write target stop-hooks using the ScriptInterpreter."
This temporarily reverts commit b65966cff6
while Jim figures out why the test is failing on the bots.
2020-09-28 09:04:32 -07:00
Jim Ingham b65966cff6 Add the ability to write target stop-hooks using the ScriptInterpreter.
Differential Revision: https://reviews.llvm.org/D88123
2020-09-25 15:44:55 -07:00
Pavel Labath 0de1463373 [lldb] Fix Type::GetByteSize for pointer types
The function was returning an incorrect (empty) value on the first
invocation. Given that this only affected the first invocation, this
bug/typo went mostly unaffected. DW_AT_const_value were particularly
badly affected by this as the GetByteSize call is
SymbolFileDWARF::ParseVariableDIE is likely to be the first call of this
function, and its effects cannot be undone by retrying.

Depends on D86348.

Differential Revision: https://reviews.llvm.org/D86436
2020-08-27 15:37:49 +02:00
Jason Molenda 99d187a003 Update UnwindPlan dump to list if it is a trap handler func; also Command
Update the "image show-unwind" command output to show if the function
being shown is listed as a user-setting or platform trap handler.

Update the individual UnwindPlan dumps to show whether the unwind plan
is registered as a trap handler.
2020-08-25 20:53:59 -07:00
Jonas Devlieghere a842950b62 [lldb] Add a SymbolFileProvider to record and replay calls to dsymForUUID
When replaying a reproducer captured from a core file, we always use
dsymForUUID for the kernel binary. When enabled, we also use it to find
kexts. Since these files are already contained in the reproducer,
there's no reason to call out to an external tool. If the tool returns a
different result, e.g. because the dSYM got garbage collected, it will
break reproducer replay. The SymbolFileProvider solves the issue by
mapping UUIDs to module and symbol paths in the reproducer.

Differential revision: https://reviews.llvm.org/D86389
2020-08-24 15:09:08 -07:00
Raphael Isemann 5913f2591c [lldb][NFC] Remove stride parameter from GetArrayElementType
This parameter isn't used anywhere in LLDB nor the Swift downstream branch. It
also doesn't really fit into the TypeSystem APIs that usually don't return
additional related functionality via some output parameters. Also the
implementations already states that the calculated value there is wrong.

Let's remove it. If we need this functionality at some point then Swift's much
nicer `GetByteStride` function seems like the way to go.

Reviewed By: aprantl

Differential Revision: https://reviews.llvm.org/D84299
2020-08-17 10:19:51 +02:00
Raphael Isemann f974d64b37 [lldb] Deduplicate copy-pasted TypeSystemMap::GetTypeSystemForLanguage
There are two implementations for `TypeSystemMap::GetTypeSystemForLanguage`
which are both identical beside one taking a `Module` and one taking a `Target`
(and then passing that argument to the `TypeSystem::CreateInstance` function).

This merges both implementations into one function with a lambda that wraps the
different calls to `TypeSystem::CreateInstance`.

Reviewed By: #lldb, JDevlieghere

Differential Revision: https://reviews.llvm.org/D82537
2020-08-14 11:58:54 +02:00
Raphael Isemann 8af160b0b8 [lldb][NFC] Use llvm::is_contained instead of std::find in a few places 2020-08-13 14:11:28 +02:00
Adrian Prantl 02f5837363 Thread ExecutionContextScope through GetByteSize where possible (NFC-ish)
This patch has no effect for C and C++. In more dynamic languages,
such as Objective-C and Swift GetByteSize() needs to call into the
language runtime, so it's important to pass one in where possible. My
primary motivation for this is some work I'm doing on the Swift
branch, however, it looks like we are also seeing warnings in
Objective-C that this may resolve.  Everything in the SymbolFile
hierarchy still passes in nullptrs, because we don't have an execution
context in SymbolFile, since SymbolFile transcends processes.

Differential Revision: https://reviews.llvm.org/D84267
2020-07-22 08:56:29 -07:00
Logan Smith 44b43a52dc [lldb][NFC] Add 'override' where missing in source/ and tools/
These were found by Clang's new -Wsuggest-override.

This patch doesn't touch any code in unittests/, since much of it intentionally doesn't use override to avoid massive warning spam from -Winconsistent-missing-override due to the use of MOCK_*** macros.

Differential Revision: https://reviews.llvm.org/D83847
2020-07-15 11:34:47 -07:00
Fred Riss a4a00ced0c [lldb/Module] Allow for the creation of memory-only modules
Summary:
This patch extends the ModuleSpec class to include a
DataBufferSP which contains the module data. If this
data is provided, LLDB won't try to hit the filesystem
to create the Module, but use only the data stored in
the ModuleSpec.

Reviewers: labath, espindola

Subscribers: emaste, MaskRay, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D83512
2020-07-14 08:45:44 -07:00
Vedant Kumar 6cfc90b9b7 [Function] Lock the function when parsing call site info
Summary:
DWARF-parsing methods in SymbolFileDWARF which update module state
typically take the module lock. ParseCallEdgesInFunction doesn't do
this, but higher-level locking within lldb::Function (which owns the
storage for parsed call edges) is necessary.

The lack of locking could explain some as-of-yet unreproducible crashes
which occur in Function::GetTailCallingEdges(). In these crashes, the
`m_call_edges` vector is non-empty but contains a nullptr, which
shouldn't be possible. (If this vector is non-empty, it _must_ contain a
non-null unique_ptr.)

This may address rdar://55622443 and rdar://65119458.

Reviewers: jasonmolenda, friss, jingham

Subscribers: aprantl, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D83359
2020-07-09 10:37:09 -07:00
Jonas Devlieghere 06412dae82 [lldb] Use std::make_unique<> (NFC)
Update the rest of lldb to use std::make_unique<>. I used clang-tidy to
automate this, which probably missed cases that are wrapped in ifdefs.
2020-06-24 17:48:40 -07:00
Raphael Isemann 1e8e1ec00c [lldb][NFC] Remove unused DEPTH_INCREMENT in CompilerType.cpp 2020-06-19 16:35:03 +02:00
Pavel Labath 0081149f96 [lldb/DWARF] Fix PC value for artificial tail call frames for the "GNU" case
Summary:
The way that the support for the GNU dialect of tail call frames was
implemented in D80519 meant that the were reporting very bogus PC values
which pointed into the middle of an instruction: the -1 trick is
necessary for the address to resolve to the right function, but we
should still be reporting a more realistic PC value -- I say "realistic"
and not "real", because it's very debatable what should be the correct
PC value for frames like this.

This patch achieves that my moving the -1 from SymbolFileDWARF into the
stack frame computation code. The idea is that SymbolFileDWARF will
merely report whether it has provided an address of the instruction
after the tail call, or the address of the call instruction itself. The
StackFrameList machinery uses this information to set the "behaves like
frame zero" property of the artificial frames (the main thing this flag
does is it controls the -1 subtraction when looking up the function
address).

This required a moderate refactor of the CallEdge class, because it was
implicitly assuming that edges pointing after the call were real calls
and those pointing the the call insn were tail calls. The class now
carries this information explicitly -- it carries three mostly
independent pieces of information:
- an address of interest in the caller
- a bit saying whether this address points to the call insn or after it
- whether this is a tail call

Reviewers: vsk, dblaikie

Subscribers: aprantl, mgrang, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D81010
2020-06-08 14:44:36 +02:00
Pavel Labath ba03bcbc4a [lldb] Remove custom DWARF expression printing code
The llvm DWARFExpression dump is nearly identical, but better -- for
example it does print a spurious space after zero-argument expressions.

Some parts of our code (variable locations) have been already switched
to llvm-based expression dumping. This switches the remainder: unwind
plans and some unit tests.
2020-05-25 16:09:25 +02:00
Raphael Isemann bca378f68a [lldb][NFC] Overload raw_ostream operator << for ConstString
Summary: We are not doing this very often, but sometimes it's convenient when I can just << ConstStrings into llvm::errs() during testing.

Reviewers: labath, JDevlieghere

Reviewed By: labath, JDevlieghere

Subscribers: JDevlieghere

Differential Revision: https://reviews.llvm.org/D80310
2020-05-22 11:24:48 +02:00
Adrian Prantl 681466f5e6 Allow lldb-test to combine -find with -dump-clang-ast
This patch threads an lldb::DescriptionLevel through the typesystem to
allow dumping the full Clang AST (level=verbose) of any lldb::Type in
addition to the human-readable source description (default
level=full). This type dumping interface is currently not exposed
through the SBAPI.

The application is to let lldb-test dump the clang AST of search
results. I need this to test lazy type completion of clang types in
subsequent patches.

Differential Revision: https://reviews.llvm.org/D78329
2020-04-17 11:01:20 -07:00
Adrian Prantl 143d507c9f Preserve the owning module information from DWARF in the synthesized AST
Types that came from a Clang module are nested in DW_TAG_module tags
in DWARF. This patch recreates the Clang module hierarchy in LLDB and
1;95;0csets the owning module information accordingly. My primary motivation
is to facilitate looking up per-module APINotes for individual
declarations, but this likely also has other applications.

This reapplies the previously reverted commit, but without support for
ClassTemplateSpecializations, which I'm going to look into separately.

rdar://problem/59634380

Differential Revision: https://reviews.llvm.org/D75488
2020-04-09 11:09:44 -07:00