[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 2

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.c

[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 2

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.com:

1476275, 1274012, 1455035, 1364789, 1454282
1467483, 1406152, 1406255, 1454837, 1454416
1467446, 1462022, 1461909, 1420566, 1327228
1367767, 1431254, 1467299, 1312678, 1431780
1454731, 1490403

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

show more ...

Revert "[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 2"

This reverts commit b9aedd94e6796e4b4866ab4c091b736b3db58cb7.

[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 2

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.c

[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 2

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.com:

1476275, 1274012, 1455035, 1364789, 1454282
1467483, 1406152, 1406255, 1454837, 1454416
1467446, 1462022, 1461909, 1420566, 1327228
1367767, 1431254, 1467299, 1312678, 1431780
1454731, 1490403

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

show more ...

[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.

[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.com:

1094796 1095721 1095728 1095737 1095741
1095756 1095779 1095789 1095805 1214552
1229457 1232475 1274006 1274010 1293427
1364800 1364802 1364804 1364812 1364816
1374902 1374909 1384975 1399312 1420451
1431704 1454230 1454554 1454615 1454579
1454594 1454832 1457759 1458696 1461909
1467658 1487814 1487830 1487845

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

show more ...

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

Fix the unwinding plan augmentation from x86 assembly

Unwind plan augmentation should compute the plan row at offset x from
the instruction before offset x, but currently we compute it from the
inst

Fix the unwinding plan augmentation from x86 assembly

Unwind plan augmentation should compute the plan row at offset x from
the instruction before offset x, but currently we compute it from the
instruction at offset x. Note that this behavior is a regression
introduced when moving the x86 assembly inspection engine to its own
file
(https://github.com/llvm/llvm-project/commit/1c9858b298d79ce82c45a2954096718b39550109#diff-375a2be066db6f34bb9a71442c9b71fcL913);
the original version handled this properly by copying the previous
instruction out before advancing the instruction pointer.

The relevant bug with more info is here: https://bugs.llvm.org/show_bug.cgi?id=43561

Differential Revision: https://reviews.llvm.org/D68454
Patch by Jaroslav Sevcik <[email protected]>.

llvm-svn: 374342

show more ...

Support Linux signal return trampolines in frame initialization

Summary:
Add __kernel_rt_sigreturn to the list of trap handlers for Linux (it's
used as such on aarch64 at least), and __restore_rt as

Support Linux signal return trampolines in frame initialization

Summary:
Add __kernel_rt_sigreturn to the list of trap handlers for Linux (it's
used as such on aarch64 at least), and __restore_rt as well (used on
x86_64).

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

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

Reviewers: labath, jankratochvil, compnerd, jfb, jasonmolenda

Reviewed By: jasonmolenda

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

Tags: #lldb

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

llvm-svn: 366580

show more ...

Fix -Wsign-compare by explicit cast after r362557

llvm-svn: 362570

Call abs to avoid signed/unsigned comparison warning.

llvm-svn: 362557

[lldb] Fix out-of-bounds read after c3ea7c66fec021867e005ad1b02f3c7e80feaa85
"Add support for mid-function epilogues on x86 that end in a non-local jump."

Detected by asan.

llvm-svn: 362510

Add support for mid-function epilogues on x86 that end in a non-local jump.

The x86 assembly inspection engine has code to support detecting a
mid-function epilogue that ends in a RET instruction; a

Add support for mid-function epilogues on x86 that end in a non-local jump.

The x86 assembly inspection engine has code to support detecting a
mid-function epilogue that ends in a RET instruction; add support for
recognizing an epilogue that ends in a JMP, and add a check that the
unwind state has been restored to the original stack setup; reinstate
the post-prologue unwind state after this JMP instruction.

The assembly inspection engine used for other architectures,
UnwindAssemblyInstEmulation, detects mid-function epilogues by
tracking branch instructions within the function and "forwards"
the current unwind state to the targets of the branches. If
an epilogue unwinds the stack and exits, followed by a branch
target, we get back to the correct unwind state. The x86
unwinder should move to this same algorithm, or possibly even
look at implementing an x86 instruction emulation plugin and
get UnwindAssemblyInstEmulation to work for x86 too. I added
a branch instruction recognizier method that will be necessary
if we want to switch the algorithm.

Differential Revision: https://reviews.llvm.org/D62764
<rdar://problem/51074422>

llvm-svn: 362456

show more ...

Use std::make_shared in LLDB (NFC)

Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared

Use std::make_shared in LLDB (NFC)

Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared to ::reset(new), it also performs a single
heap allocation for the object and control block.

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

llvm-svn: 353764

show more ...

Fix x86 return pattern detection

Summary: Replace 0xc9 (LEAVE) with 0xcb (RETF) in ret_pattern_p(). Also put 0xc3 first, since it is the most common form and will match first.

Reviewers: jasonmolen

Fix x86 return pattern detection

Summary: Replace 0xc9 (LEAVE) with 0xcb (RETF) in ret_pattern_p(). Also put 0xc3 first, since it is the most common form and will match first.

Reviewers: jasonmolenda

Reviewed By: jasonmolenda

Subscribers: labath, lldb-commits

Tags: #lldb

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

llvm-svn: 353643

show more ...

[x64] Process the B field of the REX prefix correctly for the PUSH and POP
instructions

Summary: This patch makes `x86AssemblyInspectionEngine` to process zero value of
the `B` field of the `REX` pr

[x64] Process the B field of the REX prefix correctly for the PUSH and POP
instructions

Summary: This patch makes `x86AssemblyInspectionEngine` to process zero value of
the `B` field of the `REX` prefix in a correct way for `PUSH` and `POP`
instructions. MSVC sometimes emits `pushq %rbp` instruction as `0x40 0x55`, and
it was not parsed correctly before.

Reviewers: jasonmolenda, labath

Reviewed By: jasonmolenda, labath

Subscribers: abidh, lldb-commits

Tags: #lldb

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

llvm-svn: 353281

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Simplify Boolean expressions

This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:

run-clang-tidy.py -checks='-*,readability-simplify-

Simplify Boolean expressions

This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:

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

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

llvm-svn: 349215

show more ...

[x86] Fix issues with a realigned stack in MSVC compiled applications

Summary:
This patch fixes issues with a stack realignment.

MSVC maintains two frame pointers (`ebx` and `ebp`) for a realigned

[x86] Fix issues with a realigned stack in MSVC compiled applications

Summary:
This patch fixes issues with a stack realignment.

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

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

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

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

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

Reviewers: labath, zturner, jasonmolenda, stella.stamenova

Reviewed By: jasonmolenda

Subscribers: abidh, lldb-commits

Tags: #lldb

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

llvm-svn: 345577

show more ...

Reflow paragraphs in comments.

This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to r

Reflow paragraphs in comments.

This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.

FYI, the script I used was:

import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue

if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)

continue

if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""

out.write(line)

os.rename(tmp, sys.argv[1])

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

llvm-svn: 331197

show more ...

The x86 instruction unwinder can be asked to disassemble non-instruction
blocks of memory, and if the final bytes of that block look like a long
x86 instruction, it can cause the llvm disassembler t

The x86 instruction unwinder can be asked to disassemble non-instruction
blocks of memory, and if the final bytes of that block look like a long
x86 instruction, it can cause the llvm disassembler to read past the end
of the buffer. Use the maximum allowed instruction length that we pass
to the llvm disassembler as a way to limit this to the size of the buffer.

An example of how to trigger this is when lldb does a function call, it
puts a breakpoint on the beginning of main() and uses that as the return
address from the function call. When we stop at that location, lldb may
try to find the first frame up the stack. Because this is on the first
instruction of a function, it will get the word-size value at the stack
pointer and assume that this was the caller's pc value. But this is random
stack memory and could point to anything - an object in memory, something
in the data section, whatever. And if we have a symbol for that thing,
we'll try to disassemble it.

This was leading to infrequent crashes in customer scenarios; figured out
what was happening with address sanitizer.

<rdar://problem/30463256>

llvm-svn: 307454

show more ...

[UnwindAssembly/x86] Add support for "lea imm(%ebp), %esp" pattern

Summary:
The instruction pattern:
and $-16, %esp
sub $imm, %esp
...
lea imm(%ebp), %esp

appears when the compiler is realigning th

[UnwindAssembly/x86] Add support for "lea imm(%ebp), %esp" pattern

Summary:
The instruction pattern:
and $-16, %esp
sub $imm, %esp
...
lea imm(%ebp), %esp

appears when the compiler is realigning the stack (for example in
main(), or almost everywhere with -mstackrealign switch). The "and"
instruction is very difficult to model, but that's not necessary, as
these frames are always %ebp-based (the compiler also needs a way to
restore the original %esp). Therefore the plans we were generating for
these function were almost correct already. The only place we were doing
it wrong were the last instructions of the epilogue (usually just
"ret"), where we had to revert to %esp-based unwinding, as the %ebp had
been popped already.

This was wrong because our "distance of esp from cfa" counter had picked
up the "sub" instruction (and incremented the counter) but it had not
seen that the register was reset by the "lea" instruction.

This patch fixes that shortcoming, and adds a test for handling
functions like this.

I have not been able to tickle the compiler into producing a 64-bit
function with this pattern, but I don't see a reason why it couldn't
produce it, if it chose to, so I add a x86_64 test as well.

Reviewers: jasonmolenda, tberghammer

Subscribers: lldb-commits

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

llvm-svn: 306666

show more ...

x86AssemblyInspectionEngine::AugmentUnwindPlanFromCallSite could access
the byte past the end of the buffer it had been given. ASAN catch.
<rdar://problem/30774863>

llvm-svn: 296733

Finish adding the individual instruction tests to the x86 unwinder
unittests. If I have time, I'd like to see if I can write some
tests of the eh_frame augmentation which is a wholly separate code
p

Finish adding the individual instruction tests to the x86 unwinder
unittests. If I have time, I'd like to see if I can write some
tests of the eh_frame augmentation which is a wholly separate code
path (it seems like maybe it should be rolled into the main instruction
scanning codepath, to be honest, and operate on the generated
UnwindPlan instead of bothering with raw instructions at all).

Outside the eh_frame augmentation, I'm comfortable that this unwind
generator is being tested well now.

llvm-svn: 283186

show more ...

Add support for some extended push instructions in i386/x86_64 like
'push 0x20(%esp)' which clang can generate when emitting
-fomit-frame-pointer code for 32-bit.

Add a unit test program which inclu

Add support for some extended push instructions in i386/x86_64 like
'push 0x20(%esp)' which clang can generate when emitting
-fomit-frame-pointer code for 32-bit.

Add a unit test program which includes this instruction.

Also fix a bug in the refactoring/rewrite of the x86 assembly
instruction profiler where I'd hard coded it as a 64-bit disassembler
instead of using the ArchSpec to pick a 32-bit or 64-bit disassembler
from llvm. When the disassembler would hit an instruction
that is invalid in 64-bit mode, it would stop disassembling the function.
This likely led to the TestSBData testsuite failure on linux with 32-bit
i386 and gcc-4.9; I'll test that in a bit.

The newly added unit test program is 32-bit i386 code and it includes
an instruction which is invalid in 64-bit mode so it will catch this.

<rdar://problem/28557876>

llvm-svn: 282991

show more ...

Re-commit the changes from r282565 that I had to back out because of
a linux bot test failure. That one is fixed; hopefully there won't
be any others turned up this time.

The eh_frame augmentation

Re-commit the changes from r282565 that I had to back out because of
a linux bot test failure. That one is fixed; hopefully there won't
be any others turned up this time.

The eh_frame augmentation code wasn't working right after the
reorg/rewrite of the classes. It works correctly now for the one
test that was failing - but we'll see what the test bots come up
with.

<rdar://problem/28509178>

llvm-svn: 282659

show more ...

Refactor the x86 UnwindAssembly class into a separate class called
x86AssemblyInspectionEngine and the current UnwindAssembly_x86 to
allow for the core engine to be exercised by unit tests.

The Unwi

Refactor the x86 UnwindAssembly class into a separate class called
x86AssemblyInspectionEngine and the current UnwindAssembly_x86 to
allow for the core engine to be exercised by unit tests.

The UnwindAssembly_x86 class will have access to Targets, Processes,
Threads, RegisterContexts -- it will be working in the full lldb
environment.

x86AssemblyInspectionEngine is layered away from all of that, it is
given some register definitions and a bag of bytes to profile.

I wrote an initial unittest for a do-nothing simple x86_64/i386
function to start with. I'll be adding more.

The x86 assembly unwinder was added to lldb early in its bringup;
I made some modernization changes as I was refactoring the code
to make it more consistent with how we write lldb today.

I also added RegisterContextMinidump_x86_64.cpp to the xcode project
file so I can run the unittests from that.

The testsuite passes with this change, but there was quite a bit of
code change by the refactoring and it's possible there are some
issues. I'll be testing this more in the coming days, but it looks
like it is behaving correctly as far as I can tell with automated
testing.

<rdar://problem/28509178>

llvm-svn: 282565

show more ...