Commit Graph

24844 Commits

Author SHA1 Message Date
Muhammad Omair Javaid 1fa7023585 [LLDB] dotest.py set selected_platform on remote connection
This patch fixes a bug in dotest.py where lldb.selected_platform was
being set to host platform even after a successful connection to a
remote platform via platform url. This patch fixes this behavior and
sets selected_platform to remote_platform after a successful connection.

This patch also removes target_platform variable from run_suite.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D105060
2021-06-28 21:37:12 +00:00
Melanie Blower 1d85d0879a Revert "[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options"
This reverts commit 2dbe1c675f.
More buildbot failures
2021-06-28 15:47:21 -04:00
Melanie Blower 2dbe1c675f [clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options
Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D104729
2021-06-28 15:09:53 -04:00
Raphael Isemann 355541a1b7 [lldb] Avoid using any shell when calling xcrun.
When we run `xcrun` we don't have any user input in our command so relying on
the user's default shell doesn't make a lot of sense. If the user has set the
system shell to a something that isn't supported yet (dash, ash) then we would
run into the problem that we don't know how to escape our command string.

This patch just avoids using any shell at all as xcrun is always at the same
path.

Reviewed By: aprantl, JDevlieghere, kastiglione

Differential Revision: https://reviews.llvm.org/D104653
2021-06-28 19:53:52 +02:00
Jonas Devlieghere a4aa705d52 [lldb] Remove spurious lldb/lldb subdirectory
Remove the lldb/lldb subdirectory which I must have accidentally created
when applying a patch with the wrong prefix number.

Thank you Nico Weber for pointing this out!
2021-06-28 10:41:03 -07:00
Muhammad Omair Javaid 0f32d0034c [LLDB] Silence warnings in cli-wrapper-mpxtable.cpp
cli-wrapper-mpxtable.cpp was emitting warnings from printfs of
uint64_t on 32 bit arm build. This patch makes affected printfs
in cli-wrapper-mpxtable.cpp portable accross targets variants.
2021-06-28 02:36:14 +00:00
Jonas Devlieghere ffc0533855 [lldb] Use the non-locking variant of objc_copyRealizedClassList
Avoid standing the Objective-C runtime lock by calling
objc_copyRealizedClassList_nolock instead of objc_copyRealizedClassList.

We already guarantee that no other threads can run while we're running
this utility expression, similar to when we parse the data ourselves
from the gdb_objc_realized_classes struct.

Worst case this will crash if the list is getting edited, which won't do
any harm and we'll just try again later.

Differential revision: https://reviews.llvm.org/D104951
2021-06-25 15:02:49 -07:00
Jim Ingham 4eabb12057 Add support for the NSMutableDictionary variant: "__NSFrozenDictionaryM"
This was an oversight of the commit: bb93483c11 that
added support for the Frozen variants.  Also added a test case for the way that
currently produces one of these variants (a copy).
2021-06-25 14:59:26 -07:00
Adrian Prantl 4cf7c6c6a4 Change PathMappingList::RemapPath to return an optional result (NFC)
This is an NFC modernization refactoring that replaces the combination
of a bool return + reference argument, with an Optional return value.

Differential Revision: https://reviews.llvm.org/D104404
2021-06-25 14:15:29 -07:00
Chris Bond 4d8156ef87 [lldb-vscode] Make extension contribute breakpoints use new package.json schema
See https://code.visualstudio.com/updates/v1_42#_implement-a-debug-adapter-inside-an-extension

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D104882
2021-06-25 18:21:26 +02:00
serge-sans-paille f7b1fa6f5e [NFC] remove unreferenced function ResolveIPV4HostName
Differential Revision: https://reviews.llvm.org/D104856
2021-06-25 13:45:11 +02:00
David Spickett 6e5c4a443d [lldb] Re-enable GDB server client memory tag read tests
These were disabled in 473a3a773e
because they failed on 32 bit platforms. (Arm for sure but I assume
any 32 bit)

This was due to the printf formatter used. These assumed
that types like uint64_t/size_t would be certain size/type and
that changes on 32 bit.

Instead use "z" to print the size_t and PRI<...> formatters
for the addr_t (always uint64_t) and the int32_t.
2021-06-25 10:09:52 +00:00
Raphael Isemann c3549d4d7a [lldb] Skip TestDataFormatterSynthVal.py with GCC as the test compiler 2021-06-25 11:48:12 +02:00
Raphael Isemann 0adc66ff83 [lldb] Skip libstdc++ tests failing with GCC
Tracked in llvm.org/pr50861

These tests fail with all GCC versions I tested (8.5, 9.4, 10.3, 11.1).
2021-06-25 11:45:59 +02:00
Raphael Isemann 487ac0b3ee [lldb] Skip tests failing with GCC due to LLDB not being able to call constructors
Tracked in llvm.org/pr50814

These tests fail with all GCC versions I tested (8.5, 9.4, 10.3, 11.1).
2021-06-25 11:33:09 +02:00
David Spickett 64f98aae40 [lldb] Fix memory tag unsupported test
This corrects the test added in
31f9960c38
and temporarily patched in
3b4aad1186.

This test checks that the memory tag read
command errors when you use it on a platform
without memory tagging.
(which is why we skip the test if you actually
have MTE)

The problem with this test is that there's
two levels of unsupported each with it's own
specific error.

On anything that isn't AArch64, there's no
tagging extension we support. So you're told
that that is the case. As in "this won't ever work".

When you're on AArch64 we know that MTE could
be present on the remote and when we find that it
isn't, we tell you that instead.

Expect a different error message on AArch64 to fix
the test.
2021-06-25 08:57:05 +00:00
Muhammad Omair Javaid 975af861f3 Disable TestAArch64UnwindPAC.py for non PAC targets
TestAArch64UnwindPAC.py started failing on LLDB buildbot as underlying
hardware does not support PAC. This patch skips this test for targets
which do not support PAC feature.
2021-06-24 22:50:36 +00:00
Muhammad Omair Javaid 473a3a773e Disable check_qmemtags unit tests
check_qmemtags tests are broken on Arm 32 bits. This patch disables
these tests.

Differential Revision: https://reviews.llvm.org/D95602
2021-06-24 22:36:31 +00:00
Muhammad Omair Javaid 3b4aad1186 Fix typo in TestMemoryTag.py
TestMemoryTag.py should fail if underlying target doesnt support MTE.

Differential Revision: https://reviews.llvm.org/D97285
2021-06-24 22:19:51 +00:00
Fangrui Song f1e2d5851b [OptTable] Rename PrintHelp to printHelp
To be consistent with other member functions and match the coding standard.
2021-06-24 14:47:03 -07:00
Muhammad Omair Javaid 9ca0171a9f [LLDB] Fix broken LLDB build due MemoryTagManager.h
Commit e0f2744a11 broke LLDB build.
This patch fixes the build. Tested on Arm/AArch64 Linux.

Differential Revision: https://reviews.llvm.org/D97281
2021-06-25 02:37:55 +05:00
Martin Storsjö e50f9c419a [lldb] Rename StringRef _lower() method calls to _insensitive() 2021-06-25 00:22:01 +03:00
David Spickett 31f9960c38 [lldb][AArch64] Add "memory tag read" command
This new command looks much like "memory read"
and mirrors its basic behaviour.

(lldb) memory tag read new_buf_ptr new_buf_ptr+32
Logical tag: 0x9
Allocation tags:
[0x900fffff7ffa000, 0x900fffff7ffa010): 0x9
[0x900fffff7ffa010, 0x900fffff7ffa020): 0x0

Important proprties:
* The end address is optional and defaults to reading
  1 tag if ommitted
* It is an error to try to read tags if the architecture
  or process doesn't support it, or if the range asked
  for is not tagged.
* It is an error to read an inverted range (end < begin)
  (logical tags are removed for this check so you can
  pass tagged addresses here)
* The range will be expanded to fit the tagging granule,
  so you can get more tags than simply (end-begin)/granule size.
  Whatever you get back will always cover the original range.

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D97285
2021-06-24 17:35:45 +01:00
David Spickett 5d34362001 [lldb][AArch64] Add MTE memory tag reading to lldb
This adds GDB client support for the qMemTags packet
which reads memory tags. Following the design
which was recently committed to GDB.

https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html#General-Query-Packets
(look for qMemTags)

lldb commands will use the new Process methods
GetMemoryTagManager and ReadMemoryTags.

The former takes a range and checks that:
* The current process architecture has an architecture plugin
* That plugin provides a MemoryTagManager
* That the range of memory requested lies in a tagged range
  (it will expand it to granules for you)

If all that was true you get a MemoryTagManager you
can give to ReadMemoryTags.

This two step process is done to allow commands to get the
tag manager without having to read tags as well. For example
you might just want to remove a logical tag, or error early
if a range with tagged addresses is inverted.

Note that getting a MemoryTagManager doesn't mean that the process
or a specific memory range is tagged. Those are seperate checks.
Having a tag manager just means this architecture *could* have
a tagging feature enabled.

An architecture plugin has been added for AArch64 which
will return a MemoryTagManagerAArch64MTE, which was added in a
previous patch.

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D95602
2021-06-24 17:17:10 +01:00
David Spickett da2e614f56 [lldb][AArch64] Add memory tag reading to lldb-server
This adds memory tag reading using the new "qMemTags"
packet and ptrace on AArch64 Linux.

This new packet is following the one used by GDB.
(https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html)

On AArch64 Linux we use ptrace's PEEKMTETAGS to read
tags and we assume that lldb has already checked that the
memory region actually has tagging enabled.

We do not assume that lldb has expanded the requested range
to granules and expand it again to be sure.
(although lldb will be sending aligned ranges because it happens
to need them client side anyway)
Also we don't assume untagged addresses. So for AArch64 we'll
remove the top byte before using them. (the top byte includes
MTE and other non address data)

To do the ptrace read NativeProcessLinux will ask the native
register context for a memory tag manager based on the
type in the packet. This also gives you the ptrace numbers you need.
(it's called a register context but it also has non register data,
so it saves adding another per platform sub class)

The only supported platform for this is AArch64 Linux and the only
supported tag type is MTE allocation tags. Anything else will
error.

Ptrace can return a partial result but for lldb-server we will
be treating that as an error. To succeed we need to get all the tags
we expect.

(Note that the protocol leaves room for logical tags to be
read via qMemTags but this is not going to be implemented for lldb
at this time.)

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D95601
2021-06-24 17:02:55 +01:00
David Spickett cc05418d98 [lldb][AArch64] Fix unpack tags test case
Use %zu to print size_t vars.
2021-06-24 15:53:23 +01:00
David Spickett 8d58fbd09e [lldb][AArch64] Add memory-tagging qSupported feature
This feature "memory-tagging+" indicates that lldb-server
supports memory tagging packets. (added in a later patch)

We check HWCAP2_MTE to decide whether to enable this
feature for Linux.

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D97282
2021-06-24 15:43:20 +01:00
David Spickett e0f2744a11 [lldb][AArch64] Add class for managing memory tags
This adds the MemoryTagManager class and a specialisation
of that class for AArch64 MTE tags. It provides a generic
interface for various tagging operations.
Adding/removing tags, diffing tagged pointers, etc.

Later patches will use this manager to handle memory tags
in generic code in both lldb and lldb-server.
Since it will be used in both, the base class header is in
lldb/Target.
(MemoryRegionInfo is another example of this pattern)

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D97281
2021-06-24 15:10:01 +01:00
Walter Erquinigo f0d0612476 [NFC][trace] remove dead function
The Trace::GetCursorPosition function was never really implemented well and it's being replaced by a more correct TraceCursor object.
2021-06-23 23:18:53 -07:00
Walter Erquinigo 2aa1dd1c66 [trace] Add a TraceCursor class
As a follow up of D103588, I'm reinitiating the discussion with a new proposal for traversing instructions in a trace which uses the feedback gotten in that diff.

See the embedded documentation in TraceCursor for more information. The idea is to offer an OOP way to traverse instructions exposing a minimal interface that makes no assumptions on:

- the number of instructions in the trace (i.e. having indices for instructions might be impractical for gigantic intel-pt traces, as it would require to decode the entire trace). This renders the use of indices to point to instructions impractical. Traces are big and expensive, and the consumer should try to do look linear lookups (forwards and/or backwards) and avoid random accesses (the API could be extended though, but for now I want to dicard that funcionality and leave the API extensible if needed).
- the way the instructions are represented internally by each Trace plug-in. They could be mmap'ed from a file, exist in plain vector or generated on the fly as the user requests the data.
- the actual data structure used internally for each plug-in. Ideas like having a struct TraceInstruction have been discarded because that would make the plug-in follow a certain data type, which might be costly. Instead, the user can ask the cursor for each independent property of the instruction it's pointing at.

The way to get a cursor is to ask Trace.h for the end or being cursor or a thread's trace.

There are some benefits of this approach:
- there's little cost to create a cursor, and this allows for lazily decoding a trace as the user requests data.
- each trace plug-in could decide how to cache the instructions it generates. For example, if a trace is small, it might decide to keep everything in memory, or if the trace is massive, it might decide to keep around the last thousands of instructions to speed up local searches.
- a cursor can outlive a stop point, which makes trace comparison for live processes feasible. An application of this is to compare profiling data of two runs of the same function, which should be doable with intel pt.

Differential Revision: https://reviews.llvm.org/D104422
2021-06-23 22:28:01 -07:00
Alex Langford 5bebc0b177 [lldb] Decouple ObjCLanguage from Symtab
We can extend/modify `GetMethodNameVariants` to suit our purposes here.
What symtab is looking for is alternate names we may want to use to
search for a specific symbol, and asking for variants of a name makes
the most sense here.

Differential Revision: https://reviews.llvm.org/D104067
2021-06-23 13:49:46 -07:00
David Spickett fe63db25bc [lldb] Remove asserts in CommandReturnObject SetError and AppendError
I added asserts to these in https://reviews.llvm.org/D104525.
They are available (directly or otherwise) via the API so we
should not assert.

Restore the previous behaviour. If the message
is empty, we return early before printing anything.
For SetError don't assert that the error is a failure.

The remaining assert is in AppendRawError which
is not part of the API.

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D104778
2021-06-23 13:11:14 +00:00
Raphael Isemann 8a5165b3b9 [lldb][NFC] Remove some redundant semicolons on HostInfoMacOSX 2021-06-23 15:06:12 +02:00
David Spickett 1b1c8e4a98 [lldb] Remove CommandReturnObject's SetError(StringRef)
Replacing existing uses with AppendError.

SetError is also part of the SBI API. This remains
but instead of calling the underlying SetError it
will call AppendError.

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D104768
2021-06-23 11:25:10 +00:00
Raphael Isemann 709f8186a4 [lldb] Add missing string include to lldb-server's main 2021-06-22 19:49:10 +02:00
David Spickett a8dd7094d3 [lldb] Remove more redundant SetStatus(eReturnStatusFailed)
Mostly by converting uses of GetErrorStream to AppendError,
so that the call to SetStatus is implicit.

Some remain where it isn't certain that you'll have a message
to set, or you want the output to be on stdout.

One place in CommandObjectWatchpoint previously didn't set
the status to failed at all. However it's pretty obvious
that it should do so.

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D104697
2021-06-22 15:28:28 +00:00
Raphael Isemann 48e2d3a5c2 [lldb][NFC] Remove an outdated comment in HostInfoBase
We should *never* use static local variables in this file as this makes
unittesting the plugin code impossible (and this whole 'testing' thing has
turned out to be rather useful so far).
2021-06-22 16:48:17 +02:00
Raphael Isemann c462048cc4 [lldb][NFC] Use SubsystemRAII in XcodeSDKModuleTests 2021-06-22 13:41:01 +02:00
Muhammad Omair Javaid 28058d4cd1 [LLDB] Skip TestExitDuringExpression on aarch64/linux buildbot
TestExitDuringExpression test_exit_before_one_thread_no_unwind fails
sporadically on both Arm and AArch64 linux buildbots. This seems like
manifesting itself on a fully loaded machine. I have not found a reliable
timeout value so marking it skip for now.
2021-06-22 16:22:48 +05:00
Raphael Isemann 98e2b1a8dd [lldb] Adjust Clang version requirements for tail_call_frames tests
Those tests are all failing for older Clang versions. This is adding the
respective test decorators for the passing Clang versions to get the recently
revived matrix bot green.
2021-06-22 12:22:15 +02:00
Raphael Isemann 35cf5b1097 [lldb] Bumb Clang version requirement for TestBasicEntryValues.py to 11
The test only passes with Clang>=11 so adjust the decorator.

Failure output for Clang 10 is:

--- FileCheck trace (code=1) ---
FileCheck main.cpp -check-prefix=FUNC1-GNU

FileCheck input:
      Address: a.out[0x0000000000401127] (a.out.PT_LOAD[1]..text + 263)
      Summary: a.out`func1(int&) + 23 at main.cpp:25:1
       Module: file = "functionalities/param_entry_vals/basic_entry_values/BasicEntryValues_GNU.test_dwo/a.out", arch = "x86_64"
  CompileUnit: id = {0x00000000}, file = "functionalities/param_entry_vals/basic_entry_values/main.cpp", language = "c++11"
     Function: id = {0x400000000000010a}, name = "func1(int&)", mangled = "_Z5func1Ri", range = [0x0000000000401110-0x0000000000401129)
     FuncType: id = {0x400000000000010a}, byte-size = 0, decl = main.cpp:13, compiler_type = "void (int &)"
       Blocks: id = {0x400000000000010a}, range = [0x00401110-0x00401129)
    LineEntry: [0x0000000000401127-0x0000000000401130): functionalities/param_entry_vals/basic_entry_values/main.cpp:25:1
       Symbol: id = {0x0000002c}, range = [0x0000000000401110-0x0000000000401129), name="func1(int&)", mangled="_Z5func1Ri"

FileCheck output:

functionalities/param_entry_vals/basic_entry_values/main.cpp:23:16: error: FUNC1-GNU: expected string not found in input
 // FUNC1-GNU: name = "sink", type = "int &", location = DW_OP_GNU_entry_value
2021-06-22 11:58:05 +02:00
Walter Erquinigo bff2b9adbc Retry of [lldb-vscode] only report long running progress events
This time adding a check that should prevent the crash found in
https://lab.llvm.org/buildbot/#/builders/68/builds/14182/steps/6/logs/stdio

Differential Revision: https://reviews.llvm.org/D101128
2021-06-21 20:33:09 -07:00
Walter Erquinigo f84615a5a5 Revert "[lldb-vscode] only report long running progress events"
This reverts commit 610d474cfd.

lldb-vscode is crashing.
2021-06-21 19:42:34 -07:00
Walter Erquinigo 2e11f4e068 [lldb-vscode] Add simple DAP logs dump to investigate flakiness in tests
A few times tests have been flaky, presumably by crashed of lldb-vscode
itself. They can be caught by looking at the DAP logs, so I'm dumping
them when the session ends.
2021-06-21 19:35:05 -07:00
Walter Erquinigo 610d474cfd [lldb-vscode] only report long running progress events
When the number of shared libs is massive, there could be hundreds of
thousands of short lived progress events sent to the IDE, which makes it
irresponsive while it's processing all this data. As these small jobs
take less than a second to process, the user doesn't even see them,
because the IDE only display the progress of long operations. So it's
better not to send these events.

I'm fixing that by sending only the events that are taking longer than 5
seconds to process.
In a specific run, I got the number of events from ~500k to 100, because
there was only 1 big lib to parse.

I've tried this on several small and massive targets, and it seems to
work fine.

Differential Revision: https://reviews.llvm.org/D101128
2021-06-21 19:35:05 -07:00
Greg Clayton 4181bfe688 Clarify the "env" launch configuration setting.
A few users recently were trying to set environment values when using lldb-vscode and were unsure of the format of the "env" launch configuration setting. Clarify the exact format as when users add the "env" launch config setting, they can see this help string in the IDE.

Differential Revision: https://reviews.llvm.org/D104578
2021-06-21 16:11:16 -07:00
Walter Erquinigo 28d9fd00d4 Revert "[lldb-vscode] attempt to fix flakiness"
Revert "[lldb-vscode] only report long running progress events"

This reverts commit f2c009dbcf.
This reverts commit aa4685c0fb.
2021-06-21 10:53:49 -07:00
Raphael Isemann c197cddb16 [lldb] Add support for escaping zsh arguments
LLDB supports having globbing regexes in the process launch arguments that will
be resolved using the user's shell. This requires that we pass the launch args
to the shell and then read back the expanded arguments using LLDB's argdumper
utility.

As the shell will not just expand the globbing regexes but all special
characters, we need to escape all non-globbing charcters such as $, &, <, >,
etc. as those otherwise are interpreted and removed in the step where we expand
the globbing characters. Also because the special characters are shell-specific,
LLDB needs to maintain a list of all the characters that need to be escaped for
each specific shell.

This patch adds the list of special characters that need to be escaped for
`zsh`. Without this patch on systems where `zsh` is the user's shell (like on
all macOS systems) having any of these special characters in your arguments or
path to the binary will cause the process launch to fail. E.g., `lldb -- ./calc
1<2` is failing without this patch. The same happens if the absolute path to
`calc` is in a directory that contains for example parentheses or other special
characters.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D104627
2021-06-21 19:46:55 +02:00
Raphael Isemann 1265f05c26 [lldb] Skip TestLimitDebugInfo for Clang<7
Without DW_CC_pass_by_* attributes that Clang 7 started to emit in this test
we don't properly read back the return value of the `get_*` functions and just
read bogus memory.

See also the TestReturnValue.py test.
2021-06-21 19:46:29 +02:00
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
Raphael Isemann 7f20e6ae32 [lldb][NFC] Remove redundant deleted constructors in HostInfoBase subclasses
HostInfoBase has a deleted dtor/ctor so there is no need to do the same for
all the classes inheriting from it.

Reviewed By: DavidSpickett, JDevlieghere

Differential Revision: https://reviews.llvm.org/D104221
2021-06-21 13:33:40 +02:00
David Spickett 12ae3cb7ba [lldb] Assert that CommandResultObject error messages are not empty
The intention is now that AppendError/SetError/AppendRawError only
be called with some message to show. This enforces that.

For SetError with a Status and a fallback string first assert
that the Status is a failure Status. Then it calls SetError(StringRef)
which checks the message is valid. (which could be the fallback
or the Status')

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D104525
2021-06-21 09:44:47 +00:00
Jason Molenda af913881e3 Try to unbreak the windows CI
MSVC and clang seem to disagree with whether I can do this.
2021-06-20 13:13:46 -07:00
Jason Molenda 9ea6dd5cfa Add a corefile style option to process save-core; skinny corefiles
Add a new feature to process save-core on Darwin systems -- for
lldb to create a user process corefile with only the dirty (modified
memory) pages included.  All of the binaries that were used in the
corefile are assumed to still exist on the system for the duration
of the use of the corefile.  A new --style option to process save-core
is added, so a full corefile can be requested if portability across
systems, or across time, is needed for this corefile.

debugserver can now identify the dirty pages in a memory region
when queried with qMemoryRegionInfo, and the size of vm pages is
given in qHostInfo.

Create a new "all image infos" LC_NOTE for Mach-O which allows us
to describe all of the binaries that were loaded in the process --
load address, UUID, file path, segment load addresses, and optionally
whether code from the binary was executing on any thread.  The old
"read dyld_all_image_infos and then the in-memory Mach-O load
commands to get segment load addresses" no longer works when we
only have dirty memory.

rdar://69670807
Differential Revision: https://reviews.llvm.org/D88387
2021-06-20 12:26:54 -07:00
Michał Górny d4c437c428 [lldb] [Process/elf-core] Fix reading NetBSD/i386 core dumps
Add support for extracting basic data from NetBSD/i386 core dumps.
FPU registers are not supported at the moment.

Differential Revision: https://reviews.llvm.org/D101091
2021-06-20 18:59:21 +02:00
Walter Erquinigo f2c009dbcf [lldb-vscode] attempt to fix flakiness
There are many tests failing intermittently for lldb-vscode after
https://reviews.llvm.org/rGaa4685c0fb3aab5acb90be5fd3eb5ba8bf1e3211. I'm
unsure if this actually the culprit, so I'm softly removing that feature
to see if that fixes the issue.
2021-06-18 10:12:46 -07:00
Heejin Ahn 1d891d44f3 [WebAssembly] Rename event to tag
We recently decided to change 'event' to 'tag', and 'event section' to
'tag section', out of the rationale that the section contains a
generalized tag that references a type, which may be used for something
other than exceptions, and the name 'event' can be confusing in the web
context.

See
- https://github.com/WebAssembly/exception-handling/issues/159#issuecomment-857910130
- https://github.com/WebAssembly/exception-handling/pull/161

Reviewed By: tlively

Differential Revision: https://reviews.llvm.org/D104423
2021-06-17 20:34:19 -07:00
Walter Erquinigo bf9f21a28b [trace][intel-pt] Create basic SB API
This adds a basic SB API for creating and stopping traces.
Note: This doesn't add any APIs for inspecting individual instructions. That'd be a more complicated change and it might be better to enhande the dump functionality to output the data in binary format. I'll leave that for a later diff.

This also enhances the existing tests so that they test the same flow using both the command interface and the SB API.

I also did some cleanup of legacy code.

Differential Revision: https://reviews.llvm.org/D103500
2021-06-17 15:14:47 -07:00
Walter Erquinigo c1360fd5fc [lldb-vscode] remove failed test
Found in http://green.lab.llvm.org/green/job/lldb-cmake/32891/testReport/lldb-api/tools_lldb-vscode_launch/TestVSCode_launch_py/

the lldb-vscode changed and that test makes no sense anymore
2021-06-17 15:13:16 -07:00
Walter Erquinigo aa4685c0fb [lldb-vscode] only report long running progress events
When the number of shared libs is massive, there could be hundreds of
thousands of short lived progress events sent to the IDE, which makes it
irresponsive while it's processing all this data. As these small jobs
take less than a second to process, the user doesn't even see them,
because the IDE only display the progress of long operations. So it's
better not to send these events.

I'm fixing that by sending only the events that are taking longer than 5
seconds to process.
In a specific run, I got the number of events from ~500k to 100, because
there was only 1 big lib to parse.

I've tried this on several small and massive targets, and it seems to
work fine.

Differential Revision: https://reviews.llvm.org/D101128
2021-06-17 12:01:27 -07:00
David Spickett eaf60a4411 [lldb] Remove redundant calls to set eReturnStatusFailed
This is part 2, covering the commands source.

Some uses remain where it's tricky to see what the
logic is or they are not used with AppendError.

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D104448
2021-06-17 14:39:35 +01:00
David Spickett 7a580f3c28 [lldb] Remove redundant calls to set eReturnStatusFailed
Since https://reviews.llvm.org/D103701 AppendError<...>
sets this for you.

This change includes all of the non-command uses.

Some uses remain where it's either tricky to reason about
the logic, or they aren't paired with AppendError calls.

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D104379
2021-06-17 12:21:54 +01:00
David Spickett 983ed1b58e [lldb] Set return object failed status even if error string is empty
The idea is now that AppendError<...> will set eReturnStatusFailed
for you so you don't have to call SetStatus again.

Previously if the error message was empty, the status wouldn't
be set.

I don't think there are any sitautions where the message is in
fact empty but it potentially could be depending on where
we get the string from.

So let's set the status up front then return early if the message is empty.

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D104380
2021-06-17 12:20:52 +01:00
Raphael Isemann 25fa67868b [lldb] Skip variant/optional libc++ tests for Clang 5/6
Clang 5 and Clang 6 can no longer parse newer versions of libc++. As we can't
specify the specific libc++ version in the decorator, let's only allow Clang
versions that can parse all currently available libc++ versions.
2021-06-17 09:52:09 +02:00
Adrian Prantl 42e2a90684 Relax language comparison when matching up C++ forward decls with definitions
when dealing with -gmodules debug info.

This fixes the bot failures on Darwin.

A recent clang change (presumably https://reviews.llvm.org/D104291)
introduced a bug where .pcm files would identify themselves as
DW_LANG_C_plus_plus, but the .o that references them would identify as
DW_LANG_C_plus_plus_14. While that bug needs to be fixed, too, it
shows that the current strict comparison also isn't meaningful.

rdar://79423225
2021-06-16 18:21:43 -07:00
Adrian Prantl f9aba9a5af Move the definition of LLVM_SUPPORT_XCODE_SIGNPOSTS into llvm-config.h
since it is now used by a public header file (Signposts.h).
This fixes the standalone LLDB build.
2021-06-16 14:40:37 -07:00
Raphael Isemann 59d58863bc [lldb] Require Clang 8 for gpubnames test
This test is using -gpubnames which is only available since Clang 8. The
original Clang 7 requirement was based on the availability of
-accel-tables=Dwarf (which the test initially used before being changed to
-gpubnames in commit 15a6df52ef ).
2021-06-16 14:07:03 +02:00
Raphael Isemann 3b7795aece [lldb] vwprintw -> vw_printw in IOHandlerCursesGUI
`vwprintw` is (in theory) using the `arargs.h` va_list while `vw_printw` is
using the `stdarg.h` va_list. It seems these days they can be used
interchangeably but `vwprintw` is marked as deprecated.
2021-06-16 13:14:08 +02:00
Chen Zheng ed88e57f65 [LLDB] Fix buildbots breakage due to TestGuessLanguage.py
Fix LLDB buidbot breakage due to D104291

Differential Revision: https://reviews.llvm.org/D104291
2021-06-16 05:03:06 +00:00
Jim Ingham 80b2da42d2 Don't depend on the "run" alias doing shell expanding.
Instead dial it up explicitly.

This test started failing recently and I'm not sure why.  It also
doesn't make sense to me the replacing "run" with "process launch -X 1 --"
should make any difference - run is an alias for the latter.  But
it does pass with the change, and unless we are testing for the exact
run alias, it's better to ask for what we want explicitly.
2021-06-15 16:37:46 -07:00
Jim Ingham 479c3577fb Missed a Windows use of ValidForThisThread in the changes for
cfb96d845a.
2021-06-15 15:43:53 -07:00
Jim Ingham cfb96d845a Convert functions that were returning BreakpointOption * to BreakpointOption &.
This is an NFC cleanup.

Many of the API's that returned BreakpointOptions always returned valid ones.
Internally the BreakpointLocations usually have null BreakpointOptions, since they
use their owner's options until an option is set specifically on the location.
So the original code used pointers & unique_ptr everywhere for consistency.
But that made the code hard to reason about from the outside.

This patch changes the code so that everywhere an API is guaranteed to
return a non-null BreakpointOption, it returns it as a reference to make
that clear.

It also changes the Breakpoint to hold a BreakpointOption
member where it previously had a UP.  Since we were always filling the UP
in the Breakpoint constructor, having the UP wasn't helping anything.

Differential Revision: https://reviews.llvm.org/D104162
2021-06-15 14:34:02 -07:00
Muhammad Omair Javaid e8f998c0c5 AArch64 Linux and elf-core PAC stack unwinder support
This patch builds on D100521 and other related patches to add support
for unwinding stack on AArch64 systems with pointer authentication
feature enabled.

We override FixCodeAddress and FixDataAddress function in ABISysV_arm64
class. We now try to calculate and set code and data masks after reading
data_mask and code_mask registers exposed by AArch64 targets running Linux.

This patch utilizes core file linux-aarch64-pac.core for testing that
LLDB can successfully unwind stack frames in the presence of signed
return address after masking off ignored bits.

This patch also includes a AArch64 Linux native test case to demonstrate
successful back trace calculation in presence of pointer authentication
feature.

Differential Revision: https://reviews.llvm.org/D99944
2021-06-16 02:09:46 +05:00
Raphael Isemann b8567559cf [lldb] Make the ClassTemplateDecl merging logic in TypeSystemClang respect template parameters
DWARF doesn't describe templates itself but only actual template instantiations.
Because of that LLDB has to infer the parameters of the class template
declarations from the actual instantiations when creating the internal Clang AST
from debug info

Because there is no dedicated DIE for the class template, LLDB also creates the
`ClassTemplateDecl` implicitly when parsing a template instantiation. To avoid
creating one ClassTemplateDecls for every instantiation,
`TypeSystemClang::CreateClassTemplateDecl` will check if there is already a
`ClassTemplateDecl` in the requested `DeclContext` and will reuse a found
fitting declaration.

The logic that checks if a found class template fits to an instantiation is
currently just comparing the name of the template. So right now we map
`template<typename T> struct S;` to an instantiation with the values `S<1, 2,
3>` even though they clearly don't belong together.

This causes crashes later on when for example the Itanium mangler's
`TemplateArgManglingInfo::needExactType` method tries to find fitting the class
template parameter that fits to an instantiation value. In the example above it
will try to find the parameter for the value `2` but will just trigger a
boundary check when retrieving the parameter with index 1 from the class
template.

There are two ways we can end up with an instantiation that doesn't fit to a
class template with the same name:

1. We have two TUs with two templates that have the same name and internal
   linkage.
2. A forward declared template instantiation is emitted by GCC and Clang
   without an empty list of parameter values.

This patch makes the check for whether a class template declaration can be
reused more sophisticated by also comparing whether the parameter values can fit
to the found class template. If we can't find a fitting class template we
justcreate a second class template with the fitting parameters.

Fixes rdar://76592821

Reviewed By: kastiglione

Differential Revision: https://reviews.llvm.org/D100662
2021-06-15 19:25:07 +02:00
Adrian Prantl 073e7a08e8 Work around MSVC compiler intricacies. 2021-06-15 08:17:56 -07:00
Jan Kratochvil fffb975095 [lldb] Fix libstdc++ 11's std::unique_ptr affecting LLDB testsuite TestDataFormatterStdUniquePtr.py
libstdc++ since version 11 has a conditional compilation based on
[[no_unique_address]] availability whether one element is either
inherited or put there as a field with [[no_unique_address]].

The code comment is by teemperor.

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D104283
2021-06-15 11:19:20 +02:00
Adrian Prantl 035217ff51 Allow signposts to take advantage of deferred string substitution
One nice feature of the os_signpost API is that format string
substitutions happen in the consumer, not the logging
application. LLVM's current Signpost class doesn't take advantage of
this though and instead always uses a static "Begin/End %s" format
string.

This patch uses variadic macros to allow the API to be used as
intended. Unfortunately, the primary use-case I had in mind (the
LLDB_SCOPED_TIMER() macro) does not get much better from this, because
__PRETTY_FUNCTION__ is *not* a macro, but a static string, so
signposts created by LLDB_SCOPED_TIMER() still use a static "%s"
format string. At least LLDB_SCOPED_TIMERF() works as intended.

This reapplies the previously reverted patch with additional include
order fixes for non-modular builds of LLDB.

Differential Revision: https://reviews.llvm.org/D103575
2021-06-14 16:53:41 -07:00
Adrian Prantl 7a7c00761f Revert "Allow signposts to take advantage of deferred string substitution"
This reverts commit 03841edde7.

Unfortunately this still breaks the LLDB standalone bot.
2021-06-14 16:09:04 -07:00
Adrian Prantl 03841edde7 Allow signposts to take advantage of deferred string substitution
One nice feature of the os_signpost API is that format string
substitutions happen in the consumer, not the logging
application. LLVM's current Signpost class doesn't take advantage of
this though and instead always uses a static "Begin/End %s" format
string.

This patch uses variadic macros to allow the API to be used as
intended. Unfortunately, the primary use-case I had in mind (the
LLDB_SCOPED_TIMER() macro) does not get much better from this, because
__PRETTY_FUNCTION__ is *not* a macro, but a static string, so
signposts created by LLDB_SCOPED_TIMER() still use a static "%s"
format string. At least LLDB_SCOPED_TIMERF() works as intended.

This reapplies the previsously reverted patch with additional MachO.h
macro #undefs.

Differential Revision: https://reviews.llvm.org/D103575
2021-06-14 14:19:41 -07:00
Raphael Isemann d94ce1a391 [lldb][docs] Add the missing rst anchors to the Python enum docs 2021-06-14 16:31:28 +02:00
Raphael Isemann e3d5e3193f [lldb][docs] Fix section name for InputReaderGranularity 2021-06-14 16:21:40 +02:00
David Spickett 31b9acaec5 Reland "[lldb] Set return status to failed when adding a command error"
This reverts commit ac031c8db2.

SB API usage has been corrected.
2021-06-14 14:26:47 +01:00
David Spickett ac031c8db2 Revert "[lldb] Set return status to failed when adding a command error" (and fixups)
This reverts commit f583029da3,
0f94d68a2e and
a2363c0cf9.

Due to test failures from incorrect SB API usage.
2021-06-14 12:09:42 +00:00
Raphael Isemann 11e2922bb7 [lldb][docs] Document SBType
This documents the behaviour of the different SBType functions with notes for
the language-specific behaviour for C/C++/Objective-C. All of this reflects the
current behaviour of LLDB (even though that also means some functions behave
kinda weird but at least they are now documented to be weird)

Reviewed By: #lldb, mib

Differential Revision: https://reviews.llvm.org/D103454
2021-06-14 13:19:19 +02:00
David Spickett f583029da3 [lldb] Correct "else if" to "elif" in TestRegisters 2021-06-14 09:36:00 +00:00
David Spickett 0f94d68a2e [lldb] Add missing changes to a2363c0cf9
Completely forgot to actually update the change before relanding it.
This adds the Darwin AVX changes.
2021-06-14 09:23:30 +00:00
David Spickett a2363c0cf9 Reland "[lldb] Set return status to failed when adding a command error"
This reverts commit db93e4e70a.

This modifies TestRegsters.py to account for Darwin showing
AVX registers as part of "Floating Point Registers" instead
of in a separate "Advanced Vector Extensions" category.
2021-06-14 09:19:25 +00:00
Florian Hahn b4583a5ad7
Revert "Allow signposts to take advantage of deferred string substitution"
This reverts commit 4fc93a3a1f because it
breaks LLDB builds on certain macOS platform & SDK combinations, e.g.
http://green.lab.llvm.org/green/job/lldb-cmake-standalone/3288/consoleFull#-195476041949ba4694-19c4-4d7e-bec5-911270d8a58c
2021-06-12 12:08:25 +01:00
Adrian Prantl 8fb53dca2f Improve materializer error messages to include type names.
rdar://79201552
2021-06-11 17:59:00 -07:00
Adrian Prantl 4fc93a3a1f Allow signposts to take advantage of deferred string substitution
One nice feature of the os_signpost API is that format string
substitutions happen in the consumer, not the logging
application. LLVM's current Signpost class doesn't take advantage of
this though and instead always uses a static "Begin/End %s" format
string.

This patch uses variadic macros to allow the API to be used as
intended. Unfortunately, the primary use-case I had in mind (the
LLDB_SCOPED_TIMER() macro) does not get much better from this, because
__PRETTY_FUNCTION__ is *not* a macro, but a static string, so
signposts created by LLDB_SCOPED_TIMER() still use a static "%s"
format string. At least LLDB_SCOPED_TIMERF() works as intended.

This reapplies the previsously reverted patch with support for
platforms where signposts are unavailable.

Differential Revision: https://reviews.llvm.org/D103575
2021-06-11 16:52:34 -07:00
Adrian Prantl b90f9bea96 Revert "Allow signposts to take advantage of deferred string substitution"
I forgot to make the LLDB macro conditional on Linux.

This reverts commit 541ccd1c1b.
2021-06-11 16:46:34 -07:00
Adrian Prantl 635b72136e Disambiguate usage of struct mach_header and other MachO definitions.
Unfortunately the Darwin signpost header also pulls in the system
MachO header and so we need to make sure to use the LLVM versions of
those definitions.
2021-06-11 16:35:43 -07:00
Adrian Prantl 541ccd1c1b Allow signposts to take advantage of deferred string substitution
One nice feature of the os_signpost API is that format string
substitutions happen in the consumer, not the logging
application. LLVM's current Signpost class doesn't take advantage of
this though and instead always uses a static "Begin/End %s" format
string.

This patch uses variadic macros to allow the API to be used as
intended. Unfortunately, the primary use-case I had in mind (the
LLDB_SCOPED_TIMER() macro) does not get much better from this, because
__PRETTY_FUNCTION__ is *not* a macro, but a static string, so
signposts created by LLDB_SCOPED_TIMER() still use a static "%s"
format string. At least LLDB_SCOPED_TIMERF() works as intended.

Differential Revision: https://reviews.llvm.org/D103575
2021-06-11 16:35:43 -07:00
Raphael Isemann 60fde9542a [lldb] Remove GCC XFAIL for TestCPPAuto and TestClassTemplateParameterPack
Both tests are passing for GCC>8 on Linux so let's mark them as passing.

TestCPPAuto was originally disabled due to "an problem with debug info generation"
in ea35dbeff2 .

TestClassTemplateParameterPack was disabled without explanation in
0f01fb39e3 .
2021-06-11 23:22:26 +02:00
Jonas Devlieghere fc71a5c6e8 [lldb] Support new objective-c hash table layout
Update LLDB for thew new Objective-C hash table layout in the dyld
shared cache found in macOS Monterey.

rdar://72863911
2021-06-11 10:26:16 -07:00
Jonas Devlieghere c7dee6aefd [lldb] Enable TestRuntimeTypes on Apple Silicon 2021-06-11 10:24:41 -07:00
Ayush Sahay 5ef5177145 [lldb-vscode] Synchronize calls to SendTerminatedEvent
If an inferior exits prior to the processing of a disconnect request,
then the threads executing EventThreadFunction and request_discontinue
respectively may call SendTerminatedEvent simultaneously, in turn,
testing and/or setting g_vsc.sent_terminated_event without any
synchronization. In case the thread executing EventThreadFunction sets
it before the thread executing request_discontinue has had a chance to
test it, the latter would move ahead to issue a response to the
disconnect request. Said response may be dispatched ahead of the
terminated event compelling the client to terminate the debug session
without consuming any console output that might've been generated by
the execution of terminateCommands.

Reviewed By: clayborg, wallace

Differential Revision: https://reviews.llvm.org/D103609
2021-06-11 21:37:19 +05:30
Raphael Isemann ab46490dfc [lldb] Remove GCC XFAIL for TestTypedefArray
This passes with GCC>8.5 and ToT LLDB.
2021-06-11 16:24:59 +02:00
Raphael Isemann b1603cb66f [lldb] Fix compilation after removal of APInt::toString 2021-06-11 16:20:57 +02:00
Raphael Isemann e2d0798bc3 [lldb] Unmark TestInlines as XFAIL for gcc
This works for GCC>8.5 and ToT LLDB.
2021-06-11 16:06:39 +02:00