[lldb] LLVM_FALLTHROUGH => [[fallthrough]]. NFC

[lldb] Remove redundant member initialization (NFC)

Identified with readability-redundant-member-init.

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

Use value instead of getValue (NFC)

[lldb] Refactor command option enum values (NFC)

Refactor the command option enum values and the command argument table
to connect the two. This has two benefits:

- We guarantee that two options t

[lldb] Refactor command option enum values (NFC)

Refactor the command option enum values and the command argument table
to connect the two. This has two benefits:

- We guarantee that two options that use the same argument type have
the same accepted values.
- We can print the enum values and their description in the help
output. (D129707)

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

show more ...

[lld] Don't use Optional::hasValue (NFC)

This patch replaces x.hasValue() with x where x is contextually
convertible to bool.

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

Don't use Optional::getValue (NFC)

[lldb/Commands] Prevent crash due to reading memory from page zero.

Adds a check to ensure that a process exists before attempting to get
its ABI to prevent lldb from crashing due to trying to read

[lldb/Commands] Prevent crash due to reading memory from page zero.

Adds a check to ensure that a process exists before attempting to get
its ABI to prevent lldb from crashing due to trying to read from page zero.

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

show more ...

[lldb] Add --show-tags option to "memory find"

This is off by default. If you get a result and that
memory has memory tags, when --show-tags is given you'll
see the tags inline with the memory conte

[lldb] Add --show-tags option to "memory find"

This is off by default. If you get a result and that
memory has memory tags, when --show-tags is given you'll
see the tags inline with the memory content.

```
(lldb) memory read mte_buf mte_buf+64 --show-tags
<...>
0xfffff7ff8020: 00 00 00 00 00 00 00 00 0d f0 fe ca 00 00 00 00 ................ (tag: 0x2)
<...>
(lldb) memory find -e 0xcafef00d mte_buf mte_buf+64 --show-tags
data found at location: 0xfffff7ff8028
0xfffff7ff8028: 0d f0 fe ca 00 00 00 00 00 00 00 00 00 00 00 00 ................ (tags: 0x2 0x3)
0xfffff7ff8038: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ (tags: 0x3 0x4)
```

The logic for handling alignments is the same as for memory read
so in the above example because the line starts misaligned to the
granule it covers 2 granules.

Depends on D125089

Reviewed By: omjavaid

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

show more ...

Reland "[lldb] Add --all option to "memory region""

This reverts commit 3e928c4b9dfb01efd2cb968795e605760828e873.

This fixes an issue seen on Windows where we did not properly
get the section names

Reland "[lldb] Add --all option to "memory region""

This reverts commit 3e928c4b9dfb01efd2cb968795e605760828e873.

This fixes an issue seen on Windows where we did not properly
get the section names of regions if they overlapped. Windows
has regions like:
[0x00007fff928db000-0x00007fff949a0000) ---
[0x00007fff949a0000-0x00007fff949a1000) r-- PECOFF header
[0x00007fff949a0000-0x00007fff94a3d000) r-x .hexpthk
[0x00007fff949a0000-0x00007fff94a85000) r-- .rdata
[0x00007fff949a0000-0x00007fff94a88000) rw- .data
[0x00007fff949a0000-0x00007fff94a94000) r-- .pdata
[0x00007fff94a94000-0x00007fff95250000) ---

I assumed that you could just resolve the address and get the section
name using the start of the region but here you'd always get
"PECOFF header" because they all have the same start point.

The usual command repeating loop used the end address of the previous
region when requesting the next, or getting the section name.
So I've matched this in the --all scenario.

In the example above, somehow asking for the region at
0x00007fff949a1000 would get you a region that starts at
0x00007fff949a0000 but has a different end point. Using the load
address you get (what I assume is) the correct section name.

show more ...

[lldb] Change implementation of memory read --show-tags option

This does 2 things:
* Moves it after the short options. Which makes sense given it's
a niche, default off option.
(if 2 files for o

[lldb] Change implementation of memory read --show-tags option

This does 2 things:
* Moves it after the short options. Which makes sense given it's
a niche, default off option.
(if 2 files for one option seems a bit much, I am going to reuse
them for "memory find" later)
* Fixes the use of repeated commands. For example:
memory read buf --show-tags
<shows tags>
memory read
<shows tags>

Added tests for the repetition and updated existing help tests.

Reviewed By: omjavaid

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

show more ...

Revert "[lldb] Add --all option to "memory region""

This reverts commit 8e648f195c3d57e573fdd8023edcfd80e0516c61
due to test failures on Windows:
https://lab.llvm.org/buildbot/#/builders/83/builds/1

Revert "[lldb] Add --all option to "memory region""

This reverts commit 8e648f195c3d57e573fdd8023edcfd80e0516c61
due to test failures on Windows:
https://lab.llvm.org/buildbot/#/builders/83/builds/19094

show more ...

[lldb] Add --all option to "memory region"

This adds an option to the memory region command
to print all regions at once. Like you can do by
starting at address 0 and repeating the command
manually.

[lldb] Add --all option to "memory region"

This adds an option to the memory region command
to print all regions at once. Like you can do by
starting at address 0 and repeating the command
manually.

memory region [-a] [<address-expression>]

(lldb) memory region --all
[0x0000000000000000-0x0000000000400000) ---
[0x0000000000400000-0x0000000000401000) r-x <...>/a.out PT_LOAD[0]
<...>
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
[0x0001000000000000-0xffffffffffffffff) ---

The output matches exactly what you'd get from
repeating the command. Including that it shows
unmapped areas between the mapped regions.

(this is why Process GetMemoryRegions is not
used, that skips unmapped areas)

Help text has been updated to show that you can have
an address or --all but not both.

Reviewed By: JDevlieghere

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

show more ...

[lldb] Add FixAnyAddress to ABI plugins

FixAnyAddress is to be used when we don't know or don't care
whether we're fixing a code or data address.

By using FixAnyAddress over the others, you documen

[lldb] Add FixAnyAddress to ABI plugins

FixAnyAddress is to be used when we don't know or don't care
whether we're fixing a code or data address.

By using FixAnyAddress over the others, you document that no
specific choice was made.

On all existing platforms apart from Arm Thumb, you could use
either FixCodeAddress or FixDataAddress and be fine. Up until
now I've chosen to use FixDataAddress but if I had
chosen to use FixCodeAddress that would have broken Arm Thumb.

Hence FixAnyAddress, to give you the "safest" option when you're
in generic code.

Uses of FixDataAddress in memory region code have been changed
to FixAnyAddress. The functionality is unchanged.

Reviewed By: omjavaid, JDevlieghere

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

show more ...

[lldb] Handle empty search string in "memory find"

Given that you'd never find empty string, just error.

Also add a test that an invalid expr generates an error.

Reviewed By: JDevlieghere

Differe

[lldb] Handle empty search string in "memory find"

Given that you'd never find empty string, just error.

Also add a test that an invalid expr generates an error.

Reviewed By: JDevlieghere

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

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

[lldb] Return a DataBuffer from FileSystem::CreateDataBuffer (NFC)

The concrete class (DataBufferLLVM) is an implementation detail.

[LLDB] Applying clang-tidy modernize-use-equals-default over LLDB

Applied modernize-use-equals-default clang-tidy check over LLDB.

This check is already present in the lldb/.clang-tidy config.

Dif

[LLDB] Applying clang-tidy modernize-use-equals-default over LLDB

Applied modernize-use-equals-default clang-tidy check over LLDB.

This check is already present in the lldb/.clang-tidy config.

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

show more ...

[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB

Applied modernize-use-default-member-init clang-tidy check over LLDB.
It appears in many files we had already switched to in cl

[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB

Applied modernize-use-default-member-init clang-tidy check over LLDB.
It appears in many files we had already switched to in class member init but
never updated the constructors to reflect that. This check is already present in
the lldb/.clang-tidy config.

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

show more ...

Add a repeat command option for "thread backtrace --count N".

This way if you have a long stack, you can issue "thread backtrace --count 10"
and then subsequent <Return>-s will page you through the

Add a repeat command option for "thread backtrace --count N".

This way if you have a long stack, you can issue "thread backtrace --count 10"
and then subsequent <Return>-s will page you through the stack.

This took a little more effort than just adding the repeat command, since
the GetRepeatCommand API was returning a "const char *". That meant the command
had to keep the repeat string alive, which is inconvenient. The original
API returned either a nullptr, or a const char *, so I changed the private API to
return an llvm::Optional<std::string>. Most of the patch is propagating that change.

Also, there was a little thinko in fetching the repeat command. We don't
fetch repeat commands for commands that aren't being added to history, which
is in general reasonable. And we don't add repeat commands to the history -
also reasonable. But we do want the repeat command to be able to generate
the NEXT repeat command. So I adjusted the logic in HandleCommand to work
that way.

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

show more ...

Reland "[lldb] Remove non address bits when looking up memory regions"

This reverts commit 0df522969a7a0128052bd79182c8d58e00556e2f.

Additional checks are added to fix the detection of the last mem

Reland "[lldb] Remove non address bits when looking up memory regions"

This reverts commit 0df522969a7a0128052bd79182c8d58e00556e2f.

Additional checks are added to fix the detection of the last memory region
in GetMemoryRegions or repeating the "memory region" command when the
target has non-address bits.

Normally you keep reading from address 0, looking up each region's end
address until you get LLDB_INVALID_ADDR as the region end address.
(0xffffffffffffffff)

This is what the remote will return once you go beyond the last mapped region:
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
[0x0001000000000000-0xffffffffffffffff) ---

Problem is that when we "fix" the lookup address, we remove some bits
from it. On an AArch64 system we have 48 bit virtual addresses, so when
we fix the end address of the [stack] region the result is 0.
So we loop back to the start.

[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
[0x0000000000000000-0x0000000000400000) ---

To fix this I added an additional check for the last range.
If the end address of the region is different once you apply
FixDataAddress, we are at the last region.

Since the end of the last region will be the last valid mappable
address, plus 1. That 1 will be removed by the ABI plugin.

The only side effect is that on systems with non-address bits, you
won't get that last catch all unmapped region from the max virtual
address up to 0xf...f.

[0x0000fffff8000000-0x0000fffffffdf000) ---
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
<ends here>

Though in some way this is more correct because that region is not
just unmapped, it's not mappable at all.

No extra testing is needed because this is already covered by
TestMemoryRegion.py, I simply forgot to run it on system that had
both top byte ignore and pointer authentication.

This change has been tested on a qemu VM with top byte ignore,
memory tagging and pointer authentication enabled.

Reviewed By: omjavaid

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

show more ...

[lldb] Add option to show memory tags in memory read output

This adds an option --show-tags to "memory read".

(lldb) memory read mte_buf mte_buf+32 -f "x" -s8 --show-tags
0x900fffff7ff8000: 0x00000

[lldb] Add option to show memory tags in memory read output

This adds an option --show-tags to "memory read".

(lldb) memory read mte_buf mte_buf+32 -f "x" -s8 --show-tags
0x900fffff7ff8000: 0x0000000000000000 0x0000000000000000 (tag: 0x0)
0x900fffff7ff8010: 0x0000000000000000 0x0000000000000000 (tag: 0x1)

Tags are printed on the end of each line, if that
line has any tags associated with it. Meaning that
untagged memory output is unchanged.

Tags are printed based on the granule(s) of memory that
a line covers. So you may have lines with 1 tag, with many
tags, no tags or partially tagged lines.

In the case of partially tagged lines, untagged granules
will show "<no tag>" so that the ordering is obvious.
For example, a line that covers 2 granules where the first
is not tagged:

(lldb) memory read mte_buf-16 mte_buf+16 -l32 -f"x" --show-tags
0x900fffff7ff7ff0: 0x00000000 <...> (tags: <no tag> 0x0)

Untagged lines will just not have the "(tags: ..." at all.
Though they may be part of a larger output that does have
some tagged lines.

To do this I've extended DumpDataExtractor to also print
memory tags where it has a valid execution context and
is asked to print them.

There are no special alignment requirements, simply
use "memory read" as usual. All alignment is handled
in DumpDataExtractor.

We use MakeTaggedRanges to find all the tagged memory
in the current dump, then read all that into a MemoryTagMap.

The tag map is populated once in DumpDataExtractor and re-used
for each subsequently printed line (or recursive call of
DumpDataExtractor, which some formats do).

Reviewed By: omjavaid

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

show more ...

[lldb] Ignore non-address bits in "memory find" arguments

This removes the non-address bits before we try to use
the addresses.

Meaning that when results are shown, those results won't
show non-add

[lldb] Ignore non-address bits in "memory find" arguments

This removes the non-address bits before we try to use
the addresses.

Meaning that when results are shown, those results won't
show non-address bits either. This follows what "memory read"
has done. On the grounds that non-address bits are a property
of a pointer, not the memory pointed to.

I've added testing and merged the find and read tests into one
file.

Note that there are no API side changes because "memory find"
does not have an equivalent API call.

Reviewed By: omjavaid

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

show more ...