[lldb] Make Python >= 3.8 required for LLDB 21 (#124735)

As decided on
https://discourse.llvm.org/t/rfc-lets-document-and-enforce-a-minimum-python-version-for-lldb/82731.

LLDB 20 recommended `>=

[lldb] Make Python >= 3.8 required for LLDB 21 (#124735)

As decided on
https://discourse.llvm.org/t/rfc-lets-document-and-enforce-a-minimum-python-version-for-lldb/82731.

LLDB 20 recommended `>= 3.8` but did not remove support for anything
earlier. Now we are in what will become LLDB 21, so I'm removing that
support and making
`>= 3.8` required.

See https://docs.python.org/3/c-api/apiabiversion.html#c.PY_VERSION_HEX
for the format of PY_VERSION_HEX.

show more ...

[lldb] Use PY_VERSION_HEX to simplify conditional compilation (NFC) (#114346)

Use PY_VERSION_HEX to simplify conditional compilation depending on the
Python version.

This also adds a static_asse

[lldb] Use PY_VERSION_HEX to simplify conditional compilation (NFC) (#114346)

Use PY_VERSION_HEX to simplify conditional compilation depending on the
Python version.

This also adds a static_assert to lldb-python to error out with a
meaningful diagnostic when you try building LLDB with an older Python
version in preparation for [1].

[1]
https://discourse.llvm.org/t/rfc-lets-document-and-enforce-a-minimum-python-version-for-lldb/82731/15

show more ...

[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)

(based on a conversation I had with @labath yesterday in
https://github.com/llvm/llvm-project/pull/106442)

Most AP

[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)

(based on a conversation I had with @labath yesterday in
https://github.com/llvm/llvm-project/pull/106442)

Most APIs that currently vend a Status would be better served by
returning llvm::Expected<> instead. If possibles APIs should be
refactored to avoid Status. The only legitimate long-term uses of Status
are objects that need to store an error for a long time (which should be
questioned as a design decision, too).

This patch makes the transition to llvm::Error easier by making the
places that cannot switch to llvm::Error explicit: They are marked with
a call to Status::clone(). Every other API can and should be refactored
to use llvm::Expected. In the end Status should only be used in very few
places.

Whenever an unchecked Error is dropped by Status it logs this to the
verbose API channel.

Implementation notes:

This patch introduces two new kinds of error_category as well as new
llvm::Error types. Here is the mapping of lldb::ErrorType to
llvm::Errors:
```
(eErrorTypeInvalid)
eErrorTypeGeneric llvm::StringError
eErrorTypePOSIX llvm::ECError
eErrorTypeMachKernel MachKernelError
eErrorTypeExpression llvm::ErrorList<ExpressionError>
eErrorTypeWin32 Win32Error
```

Relanding with built-in cloning support for llvm::ECError, and support
for initializing a Windows error with a NO_ERROR error code, and
modifying TestGDBRemotePlatformFile.py to support different renderings
of ENOSYS.

show more ...

Revert "[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)"

This reverts commit 40d8888f13fb54b0fe840deef23054de6544c184.
One last Windows failure remaining.

[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)

(based on a conversation I had with @labath yesterday in
https://github.com/llvm/llvm-project/pull/106442)

Most AP

[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)

(based on a conversation I had with @labath yesterday in
https://github.com/llvm/llvm-project/pull/106442)

Most APIs that currently vend a Status would be better served by
returning llvm::Expected<> instead. If possibles APIs should be
refactored to avoid Status. The only legitimate long-term uses of Status
are objects that need to store an error for a long time (which should be
questioned as a design decision, too).

This patch makes the transition to llvm::Error easier by making the
places that cannot switch to llvm::Error explicit: They are marked with
a call to Status::clone(). Every other API can and should be refactored
to use llvm::Expected. In the end Status should only be used in very few
places.

Whenever an unchecked Error is dropped by Status it logs this to the
verbose API channel.

Implementation notes:

This patch introduces two new kinds of error_category as well as new
llvm::Error types. Here is the mapping of lldb::ErrorType to
llvm::Errors:
```
(eErrorTypeInvalid)
eErrorTypeGeneric llvm::StringError
eErrorTypePOSIX llvm::ECError
eErrorTypeMachKernel MachKernelError
eErrorTypeExpression llvm::ErrorList<ExpressionError>
eErrorTypeWin32 Win32Error
```

Relanding with built-in cloning support for llvm::ECError, and support
for initializing a Windows error with a NO_ERROR error code.

show more ...

Revert "[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)"

This reverts commit b44da2446b17aaa847bf76f81a01870917f8736b.

[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)

(based on a conversation I had with @labath yesterday in
https://github.com/llvm/llvm-project/pull/106442)

Most AP

[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)

(based on a conversation I had with @labath yesterday in
https://github.com/llvm/llvm-project/pull/106442)

Most APIs that currently vend a Status would be better served by
returning llvm::Expected<> instead. If possibles APIs should be
refactored to avoid Status. The only legitimate long-term uses of Status
are objects that need to store an error for a long time (which should be
questioned as a design decision, too).

This patch makes the transition to llvm::Error easier by making the
places that cannot switch to llvm::Error explicit: They are marked with
a call to Status::clone(). Every other API can and should be refactored
to use llvm::Expected. In the end Status should only be used in very few
places.

Whenever an unchecked Error is dropped by Status it logs this to the
verbose API channel.

Implementation notes:

This patch introduces two new kinds of error_category as well as new
llvm::Error types. Here is the mapping of lldb::ErrorType to
llvm::Errors:
```
(eErrorTypeInvalid)
eErrorTypeGeneric llvm::StringError
eErrorTypePOSIX llvm::ECError
eErrorTypeMachKernel MachKernelError
eErrorTypeExpression llvm::ErrorList<ExpressionError>
eErrorTypeWin32 Win32Error
```

Relanding with built-in cloning support for llvm::ECError, and support
for initializing a Windows error with a NO_ERROR error code.

show more ...

Revert "[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)"

This reverts commit 104b249c236578d298384416c495ff7310b97f4d because
it has caused 2 test failures on Wind

Revert "[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)"

This reverts commit 104b249c236578d298384416c495ff7310b97f4d because
it has caused 2 test failures on Windows:
https://lab.llvm.org/buildbot/#/builders/141/builds/2544

Failed Tests (2):
lldb-api :: functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py
lldb-unit :: Utility/./UtilityTests.exe/StatusTest/ErrorWin32

I reckon the cause is the same, that we construct an error with the Win32
NO_ERROR value which means there was no error but we're assuming anything
with an error code is a failure.

show more ...

[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)

(based on a conversation I had with @labath yesterday in
https://github.com/llvm/llvm-project/pull/106442)

Most AP

[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)

(based on a conversation I had with @labath yesterday in
https://github.com/llvm/llvm-project/pull/106442)

Most APIs that currently vend a Status would be better served by
returning llvm::Expected<> instead. If possibles APIs should be
refactored to avoid Status. The only legitimate long-term uses of Status
are objects that need to store an error for a long time (which should be
questioned as a design decision, too).

This patch makes the transition to llvm::Error easier by making the
places that cannot switch to llvm::Error explicit: They are marked with
a call to Status::clone(). Every other API can and should be refactored
to use llvm::Expected. In the end Status should only be used in very few
places.

Whenever an unchecked Error is dropped by Status it logs this to the
verbose API channel.

Implementation notes:

This patch introduces two new kinds of error_category as well as new
llvm::Error types. Here is the mapping of lldb::ErrorType to
llvm::Errors:
```
(eErrorTypeInvalid)
eErrorTypeGeneric llvm::StringError
eErrorTypePOSIX llvm::ECError
eErrorTypeMachKernel MachKernelError
eErrorTypeExpression llvm::ErrorList<ExpressionError>
eErrorTypeWin32 Win32Error
```

Relanding with built-in cloning support for llvm::ECError.

show more ...

Revert "[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)"

This reverts commit 06939fa2e140a171132275ec0ea1857d20c5dbdd.

[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)

(based on a conversation I had with @labath yesterday in
https://github.com/llvm/llvm-project/pull/106442)

Most

[lldb] Change the implementation of Status to store an llvm::Error (NFC) (#106774)

(based on a conversation I had with @labath yesterday in
https://github.com/llvm/llvm-project/pull/106442)

Most APIs that currently vend a Status would be better served by
returning llvm::Expected<> instead. If possibles APIs should be
refactored to avoid Status. The only legitimate long-term uses of Status
are objects that need to store an error for a long time (which should be
questioned as a design decision, too).

This patch makes the transition to llvm::Error easier by making the
places that cannot switch to llvm::Error explicit: They are marked with
a call to Status::clone(). Every other API can and should be refactored
to use llvm::Expected. In the end Status should only be used in very few
places.

Whenever an unchecked Error is dropped by Status it logs this to the
verbose API channel.

Implementation notes:

This patch introduces two new kinds of error_category as well as new
llvm::Error types. Here is the mapping of lldb::ErrorType to
llvm::Errors:
```
(eErrorTypeInvalid)
eErrorTypeGeneric llvm::StringError
eErrorTypePOSIX llvm::ECError
eErrorTypeMachKernel MachKernelError
eErrorTypeExpression llvm::ErrorList<ExpressionError>
eErrorTypeWin32 Win32Error
```

show more ...

[lldb] Make conversions from llvm::Error explicit with Status::FromEr… (#107163)

…ror() [NFC]

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
ant

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form

` ResultTy DoFoo(Status& error)
`
to

` llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other
changes are mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.

show more ...

[lldb] Replace condition that always evaluates to false (#89685)

Addresses issue #87243.

The current code incorrectly checks the validity of ```obj``` twice when
it should be checking the new `

[lldb] Replace condition that always evaluates to false (#89685)

Addresses issue #87243.

The current code incorrectly checks the validity of ```obj``` twice when
it should be checking the new ```str_obj``` pointer.

Signed-off-by: Troy-Butler <squintik@outlook.com>
Co-authored-by: Troy-Butler <squintik@outlook.com>

show more ...

[lldb] Check for abstract methods implementation in Scripted Plugin Objects (#71260)

This patch enforces that every scripted object implements all the
necessary abstract methods.

Every scripted aff

[lldb] Check for abstract methods implementation in Scripted Plugin Objects (#71260)

This patch enforces that every scripted object implements all the
necessary abstract methods.

Every scripted affordance language interface can implement a list of
abstract methods name that checked when the object is instanciated.

Since some scripting affordances implementations can be derived from
template base classes, we can't check the object dictionary since it
will contain the definition of the base class, so instead, this checks
the scripting class dictionary.

Previously, for the various python interfaces, we used
`ABC.abstractmethod` decorators but this is too language specific and
doesn't work for scripting affordances that are not derived from
template base classes (i.e OperatingSystem, ScriptedThreadPlan, ...), so
this patch provides generic/language-agnostic checks for every scripted
affordance.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

Revert "[lldb] Check for abstract methods implementation in Scripted Plugin Objects (#71260)"

This reverts commit cc9ad72713405ef8f2468c7a714a137b4a3343ba since it
breaks some tests upstream:

https

Revert "[lldb] Check for abstract methods implementation in Scripted Plugin Objects (#71260)"

This reverts commit cc9ad72713405ef8f2468c7a714a137b4a3343ba since it
breaks some tests upstream:

https://lab.llvm.org/buildbot/#/builders/68/builds/63112

********************
Failed Tests (4):
lldb-api :: functionalities/gdb_remote_client/TestThreadSelectionBug.py
lldb-api :: functionalities/plugins/python_os_plugin/TestPythonOSPlugin.py
lldb-api :: functionalities/plugins/python_os_plugin/stepping_plugin_threads/TestOSPluginStepping.py
lldb-api :: functionalities/postmortem/mach-core/TestMachCore.py

show more ...

[lldb] Check for abstract methods implementation in Scripted Plugin Objects (#71260)

This patch enforces that every scripted object implements all the
necessary abstract methods.

Every scripted

[lldb] Check for abstract methods implementation in Scripted Plugin Objects (#71260)

This patch enforces that every scripted object implements all the
necessary abstract methods.

Every scripted affordance language interface can implement a list of
abstract methods name that checked when the object is instanciated.

Since some scripting affordances implementations can be derived from
template base classes, we can't check the object dictionary since it
will contain the definition of the base class, so instead, this checks
the scripting class dictionary.

Previously, for the various python interfaces, we used
`ABC.abstractmethod` decorators but this is too language specific and
doesn't work for scripting affordances that are not derived from
template base classes (i.e OperatingSystem, ScriptedThreadPlan, ...), so
this patch provides generic/language-agnostic checks for every scripted
affordance.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

[lldb] Adapt code to Python 3.13 (#70445)

1. Remove usage of PyEval_ThreadsInitialized and PyEval_InitThreads

Both of these functions were removed in Python 3.13 [1] after being
deprecated since

[lldb] Adapt code to Python 3.13 (#70445)

1. Remove usage of PyEval_ThreadsInitialized and PyEval_InitThreads

Both of these functions were removed in Python 3.13 [1] after being
deprecated since Python 3.9.

According to "What's new in Python 3.13" document [1]:

Since Python 3.7, Py_Initialize() always creates the GIL: calling
PyEval_InitThreads() did nothing and PyEval_ThreadsInitialized()
always returned non-zero.

2. Replace _Py_IsFinalizing() with Py_IsFinalizing().

[1] https://docs.python.org/3.13/whatsnew/3.13.html

show more ...

[lldb] Fix duplicate word typos; NFC

Those fixes were taken from https://reviews.llvm.org/D137338

[lldb] Add support for negative integer to {SB,}StructuredData

This patch refactors the `StructuredData::Integer` class to make it
templated, makes it private and adds 2 public specialization for bo

[lldb] Add support for negative integer to {SB,}StructuredData

This patch refactors the `StructuredData::Integer` class to make it
templated, makes it private and adds 2 public specialization for both
`int64_t` & `uint64_t` with a public type aliases, respectively
`SignedInteger` & `UnsignedInteger`.

It adds new getter for signed and unsigned interger values to the
`StructuredData::Object` base class and changes the implementation of
`StructuredData::Array::GetItemAtIndexAsInteger` and
`StructuredData::Dictionary::GetValueForKeyAsInteger` to support signed
and unsigned integers.

This patch also adds 2 new `Get{Signed,Unsigned}IntegerValue` to the
`SBStructuredData` class and marks `GetIntegerValue` as deprecated.

Finally, this patch audits all the caller of `StructuredData::Integer`
or `StructuredData::GetIntegerValue` to use the proper type as well the
various tests that uses `SBStructuredData.GetIntegerValue`.

rdar://105575764

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

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

Don't include StringSwitch (NFC)

These files do not use llvm::StringSwitch.

[lldb] Use nullptr instead of NULL (NFC)

Identified with modernize-use-nullptr.

Remove Python 2 support from the ScriptInterpreter plugin

We dropped downstream support for Python 2 in the previous release. Now
that we have branched for the next release the window where this kin

Remove Python 2 support from the ScriptInterpreter plugin

We dropped downstream support for Python 2 in the previous release. Now
that we have branched for the next release the window where this kind of
change could introduce conflicts is closing too. Start by getting rid of
Python 2 support in the Script Interpreter plugin.

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

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