[lldb] Add support for specifying a log handler

This patch adds a new flag to `log enable`, allowing the user to specify
a custom log handler. In addition to the default (stream) handler, this
allow

[lldb] Add support for specifying a log handler

This patch adds a new flag to `log enable`, allowing the user to specify
a custom log handler. In addition to the default (stream) handler, this
allows using the circular log handler (which logs to a fixed size,
in-memory circular buffer) as well as the system log handler (which logs
to the operating system log).

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

show more ...

[lldb] Support a buffered logging mode

This patch adds a buffered logging mode to lldb. A buffer size can be
passed to `log enable` with the -b flag. If no buffer size is specified,
logging is unbuf

[lldb] Support a buffered logging mode

This patch adds a buffered logging mode to lldb. A buffer size can be
passed to `log enable` with the -b flag. If no buffer size is specified,
logging is unbuffered.

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

show more ...

Add LoadTraceFromFile to SBDebugger and SBTrace

Add trace load functionality to SBDebugger via the `LoadTraceFromFile` method.
Update intelpt test case class to have `testTraceLoad` method so we can

Add LoadTraceFromFile to SBDebugger and SBTrace

Add trace load functionality to SBDebugger via the `LoadTraceFromFile` method.
Update intelpt test case class to have `testTraceLoad` method so we can take advantage of
the testApiAndSB decorator to test both the CLI and SB without duplicating code.

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

show more ...

[lldb] Remove the global platform list

This patch moves the platform creation and selection logic into the
per-debugger platform lists. I've tried to keep functional changes to a
minimum -- the main

[lldb] Remove the global platform list

This patch moves the platform creation and selection logic into the
per-debugger platform lists. I've tried to keep functional changes to a
minimum -- the main (only) observable difference in this change is that
APIs, which select a platform by name (e.g.,
Debugger::SetCurrentPlatform) will not automatically pick up a platform
associated with another debugger (or no debugger at all).

I've also added several tests for this functionality -- one of the
pleasant consequences of the debugger isolation is that it is now
possible to test the platform selection and creation logic.

This is a product of the discussion at
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>.

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

show more ...

[lldb] Use getMainExecutable in SBDebugger::PrintStackTraceOnError

Implement Pavel's suggestion to use llvm::sys::fs::getMainExecutable to
find the executable name for llvm::sys::PrintStackTraceOnEr

[lldb] Use getMainExecutable in SBDebugger::PrintStackTraceOnError

Implement Pavel's suggestion to use llvm::sys::fs::getMainExecutable to
find the executable name for llvm::sys::PrintStackTraceOnErrorSignal.

show more ...

[lldb] Add Python bindings to print stack traces on crashes.

As noticed in D87637, when LLDB crashes, we only print stack traces if
LLDB is directly executed, not when used via Python bindings. Enab

[lldb] Add Python bindings to print stack traces on crashes.

As noticed in D87637, when LLDB crashes, we only print stack traces if
LLDB is directly executed, not when used via Python bindings. Enabling
this by default may be undesirable (libraries shouldn't be messing with
signal handlers), so make this an explicit opt-in.

I "commandeered" this patch from Jordan Rupprecht who put this up for
review originally.

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

show more ...

[lldb] Expose diagnostic events through the SB API

Expose diagnostic events through the SB API. Unlike the progress events,
I opted to use a SBStructuredData so that we can add fields in the
future.

[lldb] Expose diagnostic events through the SB API

Expose diagnostic events through the SB API. Unlike the progress events,
I opted to use a SBStructuredData so that we can add fields in the
future.

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

show more ...

[lldb] Move ProgressEventData out of debugger and into its own file (NFC)

Move ProgressEventData out of debugger and into its own file. This is in
preparation of adding a few new type of event data

[lldb] Move ProgressEventData out of debugger and into its own file (NFC)

Move ProgressEventData out of debugger and into its own file. This is in
preparation of adding a few new type of event data for diagnostics.

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

show more ...

Revert "[lldb] Remove the global platform list"

It makes module dependencies loopier.

This reverts commits 49cffe3c7fab74252d4b6a073303c803dc1659f0 and
ffb9429b6f3c29ab4687b96fd85374924c98ad16.

[lldb] Remove the global platform list

This patch moves the platform creation and selection logic into the
per-debugger platform lists. I've tried to keep functional changes to a
minimum -- the main

[lldb] Remove the global platform list

This patch moves the platform creation and selection logic into the
per-debugger platform lists. I've tried to keep functional changes to a
minimum -- the main (only) observable difference in this change is that
APIs, which select a platform by name (e.g.,
Debugger::SetCurrentPlatform) will not automatically pick up a platform
associated with another debugger (or no debugger at all).

I've also added several tests for this functionality -- one of the
pleasant consequences of the debugger isolation is that it is now
possible to test the platform selection and creation logic.

This is a product of the discussion at
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>.

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

show more ...

Reland "[lldb/test] Fix TestProgressReporting.py race issue with the event listener"

This patch relands commit 3e3e79a9e4c378b59f5f393f556e6a84edcd8898, and
fixes the memory sanitizer issue describe

Reland "[lldb/test] Fix TestProgressReporting.py race issue with the event listener"

This patch relands commit 3e3e79a9e4c378b59f5f393f556e6a84edcd8898, and
fixes the memory sanitizer issue described in D120284, by removing the
output arguments from the LLDB_INSTRUMENT_VA invocation.

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

Signed-off-by: Med Ismail Bennani <[email protected]>

show more ...

[lldb] Add support for a "global" lldbinit file

This patch adds introduces a new kind of an lldbinit file. Unlike the
lldbinit in the home directory (useful for customizing lldb to the needs
of a pa

[lldb] Add support for a "global" lldbinit file

This patch adds introduces a new kind of an lldbinit file. Unlike the
lldbinit in the home directory (useful for customizing lldb to the needs
of a particular user), or the cwd lldbinit file (useful for
project-specific settings), this file can be used to customize an entire
lldb installation to a particular environment.

The feature is enabled at build time, by setting the
LLDB_GLOBAL_INIT_DIRECTORY variable to a path to a directory which
should contain an "lldbinit" file. Lldb will then load the file at
startup, if it exists, and if automatic init loading has not been
disabled. Relative paths will be resolved (at runtime) relative to the
location of the lldb library (liblldb or LLDB.framework).

The system-wide lldbinit file will be loaded first, before any
$HOME/.lldbinit and $CWD/.lldbinit files are processed, so that those
can override any system-wide settings.

More information can be found on the RFC thread at
<https://discourse.llvm.org/t/rfc-system-wide-lldbinit/59933>.

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

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

[lldb] Decouple instrumentation from the reproducers

Remove the last remaining references to the reproducers from the
instrumentation. This patch renames the relevant files and macros.

Differential

[lldb] Decouple instrumentation from the reproducers

Remove the last remaining references to the reproducers from the
instrumentation. This patch renames the relevant files and macros.

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

show more ...

[lldb] Introduce SBPlatform::SetSDKRoot

It complements the existing SBDebugger::SetCurrentPlatformSDKRoot and
allows one to set the sysroot of a platform without making it current.

Differential Rev

[lldb] Introduce SBPlatform::SetSDKRoot

It complements the existing SBDebugger::SetCurrentPlatformSDKRoot and
allows one to set the sysroot of a platform without making it current.

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

show more ...

[lldb] Remove LLDB_RECORD_DUMMY_* macros

[lldb] Remove LLDB_RECORD_CHAR_PTR_* macros

[lldb] Remove LLDB_RECORD_RESULT macro

[lldb] Remove reproducer instrumentation

This patch removes most of the reproducer instrumentation. It keeps
around the LLDB_RECORD_* macros for logging. See [1] for more details.

[1] https://lists

[lldb] Remove reproducer instrumentation

This patch removes most of the reproducer instrumentation. It keeps
around the LLDB_RECORD_* macros for logging. See [1] for more details.

[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html

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

show more ...

[lldb] Create a property to store the REPL language

Until the introduction of the C++ REPL, there was always a single REPL
language. Several places relied on this assumption through
repl_languages.G

[lldb] Create a property to store the REPL language

Until the introduction of the C++ REPL, there was always a single REPL
language. Several places relied on this assumption through
repl_languages.GetSingularLanguage. Now that this is no longer the case,
we need a way to specify a selected/preferred REPL language. This patch
does that with the help of a debugger property, taking inspiration from
how we store the scripting language.

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

show more ...

[lldb] Introduce a FreeBSDKernel plugin for vmcores

Introduce a FreeBSDKernel plugin that provides the ability to read
FreeBSD kernel core dumps. The plugin utilizes libfbsdvmcore to provide
suppor

[lldb] Introduce a FreeBSDKernel plugin for vmcores

Introduce a FreeBSDKernel plugin that provides the ability to read
FreeBSD kernel core dumps. The plugin utilizes libfbsdvmcore to provide
support for both "full memory dump" and minidump formats across variety
of architectures supported by FreeBSD. It provides the ability to read
kernel memory, as well as the crashed thread status with registers
on arm64, i386 and x86_64.

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

show more ...

[lldb] Make lldbVersion a full fledged library

Because of its dependency on clang (and potentially other compilers
downstream, such as swift) lldb_private::GetVersion already lives in its
own librar

[lldb] Make lldbVersion a full fledged library

Because of its dependency on clang (and potentially other compilers
downstream, such as swift) lldb_private::GetVersion already lives in its
own library called lldbBase. Despite that, its implementation was spread
across unrelated files. This patch improves things by introducing a
Version library with its own directory, header and implementation file.

The benefits of this patch include:

- We can get rid of the ugly quoting macros.
- Other parts of LLDB can read the version number from
lldb/Version/Version.inc.
- The implementation can be swapped out for tools like lldb-server than
don't need to depend on clang at all.

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

show more ...

Fixed use of -o and -k in LLDB under Windows when statically compiled with vcruntime.

Right now if the LLDB is compiled under the windows with static vcruntime library, the -o and -k commands will n

Fixed use of -o and -k in LLDB under Windows when statically compiled with vcruntime.

Right now if the LLDB is compiled under the windows with static vcruntime library, the -o and -k commands will not work.

The problem is that the LLDB create FILE* in lldb.exe and pass it to liblldb.dll which is an object from CRT.
Since the CRT is statically linked each of these module has its own copy of the CRT with it's own global state and the LLDB should not share CRT objects between them.

In this change I moved the logic of creating FILE* out of commands stream from Driver class to SBDebugger.
To do this I added new method: SBError SBDebugger::SetInputStream(SBStream &stream)

Command to build the LLDB:
cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb;libcxx" -DLLVM_USE_CRT_RELEASE="MT" -DLLVM_USE_CRT_MINSIZEREL="MT" -DLLVM_USE_CRT_RELWITHDEBINFO="MT" -DP
YTHON_HOME:FILEPATH=C:/Python38 -DCMAKE_C_COMPILER:STRING=cl.exe -DCMAKE_CXX_COMPILER:STRING=cl.exe ../llvm

Command which will fail:
lldb.exe -o help

See discord discussion for more details: https://discord.com/channels/636084430946959380/636732809708306432/854629125398724628
This revision is for the further discussion.

Reviewed By: teemperor

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

show more ...

[lldb] make it easier to find LLDB's python

It is surprisingly difficult to write a simple python script that
can reliably `import lldb` without failing, or crashing. I'm
currently resorting to co

[lldb] make it easier to find LLDB's python

It is surprisingly difficult to write a simple python script that
can reliably `import lldb` without failing, or crashing. I'm
currently resorting to convolutions like this:

def find_lldb(may_reexec=False):
if prefix := os.environ.get('LLDB_PYTHON_PREFIX'):
if os.path.realpath(prefix) != os.path.realpath(sys.prefix):
raise Exception("cannot import lldb.\n"
f" sys.prefix should be: {prefix}\n"
f" but it is: {sys.prefix}")
else:
line1, line2 = subprocess.run(
['lldb', '-x', '-b', '-o', 'script print(sys.prefix)'],
encoding='utf8', stdout=subprocess.PIPE,
check=True).stdout.strip().splitlines()
assert line1.strip() == '(lldb) script print(sys.prefix)'
prefix = line2.strip()
os.environ['LLDB_PYTHON_PREFIX'] = prefix

if sys.prefix != prefix:
if not may_reexec:
raise Exception(
"cannot import lldb.\n" +
f" This python, at {sys.prefix}\n"
f" does not math LLDB's python at {prefix}")
os.environ['LLDB_PYTHON_PREFIX'] = prefix
python_exe = os.path.join(prefix, 'bin', 'python3')
os.execl(python_exe, python_exe, *sys.argv)

lldb_path = subprocess.run(['lldb', '-P'],
check=True, stdout=subprocess.PIPE,
encoding='utf8').stdout.strip()

sys.path = [lldb_path] + sys.path

This patch aims to replace all that with:

#!/usr/bin/env lldb-python
import lldb
...

... by adding the following features:

* new command line option: --print-script-interpreter-info. This
prints language-specific information about the script interpreter
in JSON format.

* new tool (unix only): lldb-python which finds python and exec's it.

Reviewed By: JDevlieghere

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

show more ...