[trace] Add a flag to the decoder to output the instruction type

To build complex binding upon instruction trace, additional metadata 'instruction type' is needed.

This diff has followings:
- Add

[trace] Add a flag to the decoder to output the instruction type

To build complex binding upon instruction trace, additional metadata 'instruction type' is needed.

This diff has followings:
- Add a flag -k / --kind for instruction dump
- Remove SetGranularity and SetIgnoreErros from Trace cursor

Sample output:

```
(lldb) thread trace dump instruction -k
thread #1: tid = 3198805
libc.so.6`_IO_puts + 356
2107: 0x00007ffff7163594 ( return) retq
2106: 0x00007ffff7163592 ( other) popq %r13
2105: 0x00007ffff7163590 ( other) popq %r12
2104: 0x00007ffff716358f ( other) popq %rbp
2103: 0x00007ffff716358e ( other) popq %rbx
2102: 0x00007ffff716358c ( other) movl %ebx, %eax
2101: 0x00007ffff7163588 ( other) addq $0x8, %rsp
2100: 0x00007ffff7163570 ( cond jump) je 0x89588 ; <+344>
2099: 0x00007ffff716356e ( other) decl (%rdx)
2098: 0x00007ffff7163565 ( cond jump) je 0x8956e ; <+318>
2097: 0x00007ffff716355e ( other) cmpl $0x0, 0x33c02b(%rip) ; __libc_multiple_threads
2096: 0x00007ffff7163556 ( other) movq $0x0, 0x8(%rdx)
2095: 0x00007ffff7163554 ( cond jump) jne 0x89588 ; <+344>
2094: 0x00007ffff7163550 ( other) subl $0x1, 0x4(%rdx)
2093: 0x00007ffff7163549 ( other) movq 0x88(%rbp), %rdx
2092: 0x00007ffff7163547 ( cond jump) jne 0x89588 ; <+344>
2091: 0x00007ffff7163540 ( other) testl $0x8000, (%rbp) ; imm = 0x8000
2090: 0x00007ffff716353c ( other) cmovaq %rax, %rbx
2089: 0x00007ffff7163535 ( other) cmpq $0x7fffffff, %rbx ; imm = 0x7FFFFFFF
2088: 0x00007ffff7163530 ( other) movl $0x7fffffff, %eax ; imm = 0x7FFFFFFF
```

Reviewed By: wallace

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

show more ...

[lldb] Refactor DataBuffer so we can map files as read-only

Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
mem

[lldb] Refactor DataBuffer so we can map files as read-only

Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and
MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our
platform.

Binaries are mapped through FileSystem::CreateDataBuffer which returns a
DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer
because every DataBuffer in LLDB is considered to be writable. In order
to use a read-only llvm::MemoryBuffer I had to split our abstraction
around it.

This patch distinguishes between a DataBuffer (read-only) and
WritableDataBuffer (read-write) and updates LLDB to use the appropriate
one.

rdar://74890607

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

show more ...

Change "target.save-jit-objects" to "target.save-jit-objects-dir".
The old command wrote to CWD, which doesn't always work, and if it
didn't, there was no workaround (and it crashed on failure). Thi

Change "target.save-jit-objects" to "target.save-jit-objects-dir".
The old command wrote to CWD, which doesn't always work, and if it
didn't, there was no workaround (and it crashed on failure). This
patch changed the setting to provide a directory to save the objects
to.

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

show more ...

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
inf

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.

After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.

show more ...

[lldb] Convert "LLDB" log channel to the new API

Remove redundant return and continue statements (NFC)

Identified with readability-redundant-control-flow.

[lldb] Remove Expression's dependency on CPlusPlusLanguagePlugin

This change accomplishes the following:
- Moves `IRExecutionUnit::FindBestAlternateMangledName` to `Language`.
- Renames `FindBestAlt

[lldb] Remove Expression's dependency on CPlusPlusLanguagePlugin

This change accomplishes the following:
- Moves `IRExecutionUnit::FindBestAlternateMangledName` to `Language`.
- Renames `FindBestAlternateMangledName` to
`FindBestAlternateFunctionMangledName`
- Changes the first parameter of said method from a `ConstString`
representing a demangled name to a `Mangled`.
- Remove the use of CPlusPlusLanguage from Expression

show more ...

[lldb] Remove IRExecutionUnit::CollectFallbackNames

The work that IRExecutionUnit::CollectFallbackNames is basically the
work that `CPlusPlusLanguage::GetDemangledFunctionNameWithoutArguments`
does

[lldb] Remove IRExecutionUnit::CollectFallbackNames

The work that IRExecutionUnit::CollectFallbackNames is basically the
work that `CPlusPlusLanguage::GetDemangledFunctionNameWithoutArguments`
does already. It's also (at time or writing) specific to C++, so it can
be folded into `IRExecutionUnit::CollectCandidateCPlusPlusNames`.

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

show more ...

[lldb] Refactor and rename CPlusPlusLanguage::FindAlternateFunctionManglings

I have 2 goals with this change:
1. Disambiguate between CPlusPlus::FindAlternateFunctionManglings and
IRExecutionUnit

[lldb] Refactor and rename CPlusPlusLanguage::FindAlternateFunctionManglings

I have 2 goals with this change:
1. Disambiguate between CPlusPlus::FindAlternateFunctionManglings and
IRExecutionUnit::FindBestAlternateMangledName. These are named very
similar things, they try to do very similar things, but their
approaches are different. This change should make it clear that one
is generating possible alternate manglings (through some
heuristics-based approach) and the other is finding alternate
manglings (through searching the SymbolFile for potential matches).
2. Change GenerateAlternateFunctionManglings from a static method in
CPlusPlusLanguage to a virtual method in Language. This will allow us
to remove a direct use of CPlusPlusLanguage in IRExecutionUnit,
further pushing it to be more general. This change doesn't meet this
goal completely but allows for it to happen later.

Though this doesn't remove IRExecutionUnit's dependency on
CPlusPlusLanguage, it does bring us closer to that goal.

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

show more ...

[lldb] Delete IRExecutionUnit::SearchSpec

IRExecutionUnit::SearchSpec is a struct that encapsulates information
needed to look for a symbol. Specifically, it is comprised of a name
represented with

[lldb] Delete IRExecutionUnit::SearchSpec

IRExecutionUnit::SearchSpec is a struct that encapsulates information
needed to look for a symbol. Specifically, it is comprised of a name
represented with a ConstString and a FunctionNameType mask.
Because the mask is unused (effectively always set to
eFunctionNameTypeFull), we can remove the mask and replace all uses with
eFunctionNameTypeFull. After doing that, SearchSpec is effectively a
wrapper around a ConstString.

As an aside, SearchSpec is similar in purpose to Module::LookupInfo. I
briefly considered replacing uses of SearchSpec with LookupInfo, but
the current code only cares about symbol names (treating them as
eFunctionNameTypeFull). This code does care about language type, so
LookupInfo may be appropriate for IRExecutionUnit in the future.

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

show more ...

[lldb] Refactor IRExecutionUnit::FindInSymbols (NFC)

This patch refactors IRExecutionUnit::FindInSymbols. It eliminates a few
potential pitfalls and tries to be more explicit about the state carried

[lldb] Refactor IRExecutionUnit::FindInSymbols (NFC)

This patch refactors IRExecutionUnit::FindInSymbols. It eliminates a few
potential pitfalls and tries to be more explicit about the state carried
between symbol resolution attempts.

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

show more ...

[lldb] Use a struct to pass function search options to Module::FindFunction

Rather than passing two booleans around, which is especially error prone
with them being next to each other, use a struct

[lldb] Use a struct to pass function search options to Module::FindFunction

Rather than passing two booleans around, which is especially error prone
with them being next to each other, use a struct with named fields
instead.

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

show more ...

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,mo

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

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

https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html

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

show more ...

[Diagnose] Unify MCContext and LLVMContext diagnosing

The situation with inline asm/MC error reporting is kind of messy at the
moment. The errors from MC layout are not reliably propagated and users

[Diagnose] Unify MCContext and LLVMContext diagnosing

The situation with inline asm/MC error reporting is kind of messy at the
moment. The errors from MC layout are not reliably propagated and users
have to specify an inlineasm handler separately to get inlineasm
diagnose. The latter issue is not a correctness issue but could be improved.

* Kill LLVMContext inlineasm diagnose handler and migrate it to use
DiagnoseInfo/DiagnoseHandler.
* Introduce `DiagnoseInfoSrcMgr` to diagnose SourceMgr backed errors. This
covers use cases like inlineasm, MC, and any clients using SourceMgr.
* Move AsmPrinter::SrcMgrDiagInfo and its instance to MCContext. The next step
is to combine MCContext::SrcMgr and MCContext::InlineSrcMgr because in all
use cases, only one of them is used.
* If LLVMContext is available, let MCContext uses LLVMContext's diagnose
handler; if LLVMContext is not available, MCContext uses its own default
diagnose handler which just prints SMDiagnostic.
* Change a few clients(Clang, llc, lldb) to use the new way of reporting.

Reviewed By: MaskRay

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

show more ...

Use !hasLocalLinkage instead of listing the symbol types
we should be exporting one by one.

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

[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.

[IRExecutionUnit] Early returns for clarity. NFCI.

[lldb][NFC] Make all CompilerDeclContext parameters references instead of pointers

Summary:
All of our lookup APIs either use `CompilerDeclContext &` or `CompilerDeclContext *` semi-randomly it seem

[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

show more ...

[lldb][NFC] Remove several inefficient ConstString -> const char * -> StringRef conversions

StringRef will call strlen on the C string which is inefficient (as ConstString already
knows the string l

[lldb][NFC] Remove several inefficient ConstString -> const char * -> StringRef conversions

StringRef will call strlen on the C string which is inefficient (as ConstString already
knows the string lenght and so does StringRef). This patch replaces all those calls
with GetStringRef() which doesn't recompute the length.

show more ...

[lldb][NFCI] Remove unused LanguageType parameters

These parameters are unused in these methods, and some of them only had a
LanguageType parameter to pipe to other methods that don't use it
either.

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

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

show more ...

[lldb] Fix ARM32 inferior calls

echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()'

Actual:

[lldb] Fix ARM32 inferior calls

echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()'

Actual:

error: Expression can't be run, because there is no JIT compiled function

Expected:

<nothing, sync() has been executed>

This patch has been checked by:
D71707: clang-tidy: new bugprone-pointer-cast-widening
https://reviews.llvm.org/D71707

Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended:

echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long
long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out
<stdin>: In function ‘main’:
<stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000

With debug output:
Actual:

IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3)
Code can be run in the target.
Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff
Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv
Sections:
[0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text)
...
HandleCommand, command did not succeed
error: Expression can't be run, because there is no JIT compiled function

Expected:

IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3)
IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060].
Code can be run in the target.
Found function, has local address 0xb6fac000 and remote address 0xb6ff9020
Function's code range is [0xb6ff9020+0x40]
...
Function data has contents:
0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1
...
Function disassembly:
0xb6ff9020: 0xe92d4c10 push {r4, r10, r11, lr}

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

show more ...

[lldb/IRExecutionUnit] Stop searching based on demangled names

Summary:
This was causing problems on linux, where we'd end up calling the
deleting destructor instead of a regular one (because they h

[lldb/IRExecutionUnit] Stop searching based on demangled names

Summary:
This was causing problems on linux, where we'd end up calling the
deleting destructor instead of a regular one (because they have the same
demangled name), making a lot of mischief in the process.

The only place where this was necessary (according to the test suite, at
least) was to call a base structor instead of a complete one, but this
is now handled in a more targeted fashion.

TestCallOverriddenMethod is now re-enabled as it now passes reliably.

Reviewers: teemperor, JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

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

show more ...

[lldb] Add logging to IRExecutionUnit::GetStaticInitializers

[lldb][NFC] Early exit in IRExecutionUnit::GetStaticInitializers