[lldb] Fix typo in ProcessWindows.h

[lldb] Add a getter for the process' system architecture

This patch adds a getter for the process' system architecture. I went
with Process::GetSystemArchitecture to match
Platform::GetSystemArchite

[lldb] Add a getter for the process' system architecture

This patch adds a getter for the process' system architecture. I went
with Process::GetSystemArchitecture to match
Platform::GetSystemArchitecture.

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

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

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

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

[Windows] Add support of watchpoints to `ProcessWindows`

Summary:
This patch adds support of watchpoints to the old `ProcessWindows` plugin.

The `ProcessWindows` plugin uses the `RegisterContext` t

[Windows] Add support of watchpoints to `ProcessWindows`

Summary:
This patch adds support of watchpoints to the old `ProcessWindows` plugin.

The `ProcessWindows` plugin uses the `RegisterContext` to set and reset
watchpoints. The `RegisterContext` has some interface to access watchpoints,
but it is very limited (e.g. it is impossible to retrieve the last triggered
watchpoint with it), that's why I have implemented a slightly different
interface in the `RegisterContextWindows`. Moreover, I have made the
`ProcessWindows` plugin responsible for search of a vacant watchpoint slot,
because watchpoints exist per-process (not per-thread), then we can place
the same watchpoint in the same slot in different threads. With this scheme
threads don't need to have their own watchpoint lists, and it simplifies
identifying of the last triggered watchpoint.

Reviewers: asmith, stella.stamenova, amccarth

Reviewed By: amccarth

Subscribers: labath, zturner, leonid.mashinskiy, abidh, JDevlieghere, lldb-commits

Tags: #lldb

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

llvm-svn: 371166

show more ...

Try again to move common functionality from ProcessWindows into ProcessDebugger

This reverts commit ed499a36b67cf46cbf66052cfe374c80a595f1c1 and addresses
a problem causing a Windows build bot to ha

Try again to move common functionality from ProcessWindows into ProcessDebugger

This reverts commit ed499a36b67cf46cbf66052cfe374c80a595f1c1 and addresses
a problem causing a Windows build bot to hang.

llvm-svn: 365592

show more ...

Revert "Move common functionality from processwindows into processdebugger"

This reverts commit 9c01eaff6aa3f59d91530f47b85bb470377a7780.

The changes in this commit are causing several of the LLDB

Revert "Move common functionality from processwindows into processdebugger"

This reverts commit 9c01eaff6aa3f59d91530f47b85bb470377a7780.

The changes in this commit are causing several of the LLDB tests to hang and/or timeout.

llvm-svn: 365371

show more ...

Move common functionality from processwindows into processdebugger

Summary:
This change extracts functionalities from processwindows into a
introduced processdebugger that can be reused in native pr

Move common functionality from processwindows into processdebugger

Summary:
This change extracts functionalities from processwindows into a
introduced processdebugger that can be reused in native process
debugging.

The main reason is that the native process debugging
can't directly be based on processwindows or be implemented
as a pass-through to this plugin since the plugin has ties to
Target and Process classes that are needed in host debugging but
not necessary in native debugging.

Reviewers: labath, Hui, jfb, clayborg, amccarth

Reviewed By: labath

Subscribers: amccarth, dexonsmith, mgorny, lldb-commits

Tags: #lldb

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

llvm-svn: 364210

show more ...

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

Implement GetLoadAddress for the Windows process plugin

Summary:
When a process is loaded, update its sections with the load address to resolve any created breakpoints. For the remote debugging case

Implement GetLoadAddress for the Windows process plugin

Summary:
When a process is loaded, update its sections with the load address to resolve any created breakpoints. For the remote debugging case, the debugged process is launched remotely so GetLoadAddress is intended to pass the load address from remote to LLDB (client).


Reviewers: zturner, llvm-commits, clayborg, labath

Reviewed By: labath

Subscribers: mgorny, sas, Hui, clayborg, labath, lldb-commits

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

llvm-svn: 354099

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

[Windows] A basic implementation of memory allocations in a debuggee process

Summary:
This patch adds a basic implementation of `DoAllocateMemory` and
`DoDeallocateMemory` for Windows processes. For

[Windows] A basic implementation of memory allocations in a debuggee process

Summary:
This patch adds a basic implementation of `DoAllocateMemory` and
`DoDeallocateMemory` for Windows processes. For now it considers only the
executable permission (and always allows reads and writes).

Reviewers: zturner, asmith, stella.stamenova, labath, clayborg

Reviewed By: zturner

Subscribers: Hui, vsk, jingham, aleksandr.urakov, clayborg, abidh, teemperor, lldb-commits

Tags: #lldb

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

llvm-svn: 345815

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

Refactor LLDB's Windows process plugin (NFC)

The Windows process plugin was broken up into multiple pieces a while back in
order to share code between debugging live processes and minidumps
(postmor

Refactor LLDB's Windows process plugin (NFC)

The Windows process plugin was broken up into multiple pieces a while back in
order to share code between debugging live processes and minidumps
(postmortem) debugging. The minidump portion was replaced by a cross-platform
solution. This left the plugin split into a formerly "common" base classes and
the derived classes for live debugging. This extra layer made the code harder
to understand and work with.

This patch simplifies these class hierarchies by rolling the live debugging
concrete classes up to the base classes. Last week I posted my intent to make
this change to lldb-dev, and I didn't hear any objections.

This involved moving code and changing references to classes like
ProcessWindowsLive to ProcessWindows. It still builds for both 32- and 64-bit,
and the tests still pass on 32-bit. (Tests on 64-bit weren't passing before
this refactor for unrelated reasons.)

llvm-svn: 287770

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