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

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

This reverts commit fac3f20de55769d028bd92220e74f22fa57dd4b2.

I found this has broken how we detect the last memory r

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

This reverts commit fac3f20de55769d028bd92220e74f22fa57dd4b2.

I found this has broken how we detect the last memory region in
GetMemoryRegions/"memory region" command.

When you're debugging an AArch64 system with pointer authentication,
the ABI plugin will remove the top bit from the end address of the last
user mapped area.

(lldb)
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]

ABI plugin removes anything above the 48th bit (48 bit virtual addresses
by default on AArch64, leaving an address of 0.

(lldb)
[0x0000000000000000-0x0000000000400000) ---

You get back a mapping for 0 and get into an infinite loop.

show more ...

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

This reverts commit 5fbcf677347e38718461496d9e9e184a7a30c3fb.

ProcessDebugger is used in ProcessWindows and NativeProcessWindo

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

This reverts commit 5fbcf677347e38718461496d9e9e184a7a30c3fb.

ProcessDebugger is used in ProcessWindows and NativeProcessWindows.
I thought I was simplifying things by renaming to DoGetMemoryRegionInfo
in ProcessDebugger but the Native process side expects "GetMemoryRegionInfo".

Follow the pattern that WriteMemory uses. So:
* ProcessWindows::DoGetMemoryRegioninfo calls ProcessDebugger::GetMemoryRegionInfo
* NativeProcessWindows::GetMemoryRegionInfo does the same

show more ...

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

This reverts commit 6f5ce43b433706c3ae5c37022d6c0964b6bfadf8 due to
build failure on Windows.

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

On AArch64 we have various things using the non address bits
of pointers. This means when you lookup their containing region
you won't f

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

On AArch64 we have various things using the non address bits
of pointers. This means when you lookup their containing region
you won't find it if you don't remove them.

This changes Process GetMemoryRegionInfo to a non virtual method
that uses the current ABI plugin to remove those bits. Then it
calls DoGetMemoryRegionInfo.

That function does the actual work and is virtual to be overriden
by Process implementations.

A test case is added that runs on AArch64 Linux using the top
byte ignore feature.

Reviewed By: omjavaid

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

show more ...

[lldb] Remove ConstString from Process, ScriptInterpreter and StructuredData plugin names

Remove ConstString from DynamicLoader, JITLoader and Instruction plugin names

[lldb] Return StringRef from PluginInterface::GetPluginName

There is no reason why this function should be returning a ConstString.

While modifying these files, I also fixed several instances where

[lldb] Return StringRef from PluginInterface::GetPluginName

There is no reason why this function should be returning a ConstString.

While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.

I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.

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

show more ...

[lldb] Remove PluginInterface::GetPluginVersion

In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.

Differential Revision: https://

[lldb] Remove PluginInterface::GetPluginVersion

In all these years, we haven't found a use for this function (it has
zero callers). Lets just remove the boilerplate.

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

show more ...

[ThreadPlan] fix exec on Linux

[lldb] Prevent 'process connect' from using local-only plugins

Add a 'can_connect' parameter to Process plugin initialization, and use
it to filter plugins to these capable of remote connections. T

[lldb] Prevent 'process connect' from using local-only plugins

Add a 'can_connect' parameter to Process plugin initialization, and use
it to filter plugins to these capable of remote connections. This is
used to prevent 'process connect' from picking up a plugin that can only
be used locally, e.g. the legacy FreeBSD plugin.

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

show more ...

[trace][intel-pt] Scaffold the 'thread trace start | stop' commands

Depends on D90490.

The stop command is simple and invokes the new method Trace::StopTracingThread(thread).

On the other hand, th

[trace][intel-pt] Scaffold the 'thread trace start | stop' commands

Depends on D90490.

The stop command is simple and invokes the new method Trace::StopTracingThread(thread).

On the other hand, the start command works by delegating its implementation to a CommandObject provided by the Trace plugin. This is necessary because each trace plugin needs different options for this command. There's even the chance that a Trace plugin can't support live tracing, but instead supports offline decoding and analysis, which means that "thread trace dump instructions" works but "thread trace start" doest. Because of this and a few other reasons, it's better to have each plugin provide this implementation.

Besides, I'm using the GetSupportedTraceType method introduced in D90490 to quickly infer what's the trace plug-in that works for the current process.

As an implementation note, I moved CommandObjectIterateOverThreads to its header so that I can use it from the IntelPT plugin. Besides, the actual start and stop logic for intel-pt is not part of this diff.

Reviewed By: clayborg

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

show more ...

[lldb] Delete copy operations on PluginInterface class

This is a polymorphic class, copying it is a bad idea.

This was not a problem because most classes inheriting from it were
deleting their copy

[lldb] Delete copy operations on PluginInterface class

This is a polymorphic class, copying it is a bad idea.

This was not a problem because most classes inheriting from it were
deleting their copy operations themselves. However, this enables us to
delete those explicit deletions, and ensure noone forgets to add them in
the future.

show more ...

[lldb] NFC remove DISALLOW_COPY_AND_ASSIGN

Summary:
This is how I applied my clang-tidy check (see
https://reviews.llvm.org/D80531) in order to remove
`DISALLOW_COPY_AND_ASSIGN` and have deleted cop

[lldb] NFC remove DISALLOW_COPY_AND_ASSIGN

Summary:
This is how I applied my clang-tidy check (see
https://reviews.llvm.org/D80531) in order to remove
`DISALLOW_COPY_AND_ASSIGN` and have deleted copy ctors and deleted
assignment operators instead.

```
lang=bash
grep DISALLOW_COPY_AND_ASSIGN /opt/notnfs/kkleine/llvm/lldb -r -l | sort | uniq > files

for i in $(cat files);
do
clang-tidy \
--checks="-*,modernize-replace-disallow-copy-and-assign-macro" \
--format-style=LLVM \
--header-filter=.* \
--fix \
-fix-errors \
$i;
done
```

Reviewers: espindola, labath, aprantl, teemperor

Reviewed By: labath, aprantl, teemperor

Subscribers: teemperor, aprantl, labath, emaste, sbc100, aheejin, MaskRay, arphaman, usaxena95, lldb-commits

Tags: #lldb

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

show more ...

[lldb] Update header guards to be consistent and compliant with LLVM (NFC)

LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pa

[lldb] Update header guards to be consistent and compliant with LLVM (NFC)

LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.

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

show more ...

typedef enum -> enum

Reviewed By: labath

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

llvm-svn: 360654

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.

I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.

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

llvm-svn: 358135

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

Remove header grouping comments.

This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdate

Remove header grouping comments.

This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.

llvm-svn: 346626

show more ...

Rename Error -> Status.

This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.

A change of this magnitude cannot easily be done without
find and replace, but that h

Rename Error -> Status.

This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.

A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.

llvm-svn: 302872

show more ...

Move classes from Core -> Utility.

This moves the following classes from Core -> Utility.

ConstString
Error
RegularExpression
Stream
StreamString

The goal here is to get lldbUtility into a state w

Move classes from Core -> Utility.

This moves the following classes from Core -> Utility.

ConstString
Error
RegularExpression
Stream
StreamString

The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.

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

llvm-svn: 293941

show more ...

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging t

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.

llvm-svn: 280751

show more ...

Test commit to verify access, fix typo.

llvm-svn: 273546

Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to

Since our expression parser needs to locate areas of memory that are not in use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function.

In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly.

llvm-svn: 272276

show more ...

Change over the broadcaster/listener process to hold shared or weak pointers
to each other. This should remove some infrequent teardown crashes when the
listener is not the debugger's listener.

Pro

Change over the broadcaster/listener process to hold shared or weak pointers
to each other. This should remove some infrequent teardown crashes when the
listener is not the debugger's listener.

Processes now need to take a ListenerSP, not a Listener&.

This required changing over the Process plugin class constructors to take a ListenerSP, instead
of a Listener&. Other than that there should be no functional change.

<rdar://problem/24580184> CrashTracer: [USER] Xcode at …ework: lldb_private::Listener::BroadcasterWillDestruct + 39

llvm-svn: 262863

show more ...