WithColor has an "auto detection mode" which looks whether the
corresponding whether the corresponding cl::opt is enabled or not. While
this is great when opting into cl::opt, it's not so great for downstream
users of this utility, which might have their own competing options to
enable or disable colors. The WithColor constructor takes a color mode,
but the big benefit of the class are its static error and warning
helpers and default error handlers.
In order to allow users of this utility to enable or disable colors
globally, this patch adds the ability to specify a global auto detection
function. By default, the auto detection function behaves the way that
it does today. The benefit of this patch lies in that it can be
overwritten. In addition to a ability to change the auto detection
function, I've also made it possible to get your hands on the default
auto detection function, so you swap it back if if you so desire.
This patch allow downstream users (like LLDB) to globally disable colors
with its own command line flag.
Differential revision: https://reviews.llvm.org/D120593
WithColor has an "auto detection mode" which looks whether the
corresponding whether the corresponding cl::opt is enabled or not. While
this is great when opting into cl::opt, it's not so great for downstream
users of this utility, which might have their own competing options to
enable or disable colors. The WithColor constructor takes a color mode,
but the big benefit of the class are its static error and warning
helpers and default error handlers.
In order to allow users of this utility to enable or disable colors
globally, this patch adds the ability to specify a global auto detection
function. By default, the auto detection function behaves the way that
it does today. The benefit of this patch lies in that it can be
overwritten. In addition to a ability to change the auto detection
function, I've also made it possible to get your hands on the default
auto detection function, so you swap it back if if you so desire.
This patch allow downstream users (like LLDB) to globally disable colors
with its own command line flag.
Differential revision: https://reviews.llvm.org/D120593
SetValueFromCString and SetData methods return false if register can't
be written but they don't set a error message. It sometimes confuses
callers of these methods because they try to get the error message in case of
failure but Status::AsCString returns nullptr.
For example, lldb-vscode crashes due to this bug if some register can't
be written. It invokes SBError::GetCString in case of error and doesn't
check whether the result is nullptr (see request_setVariable implementation in
lldb-vscode.cpp for more info).
Reviewed By: labath, clayborg
Differential Revision: https://reviews.llvm.org/D120319
See post-commit discussion on https://reviews.llvm.org/D120305.
This change breaks the clang-ppc64le-rhel buildbot, though
there is suspicion that it's an issue with the bot. The change
also had a larger than expected impact on compile-time and
code-size.
This reverts commit 3c4ed02698
and some followup changes.
This checks `m_fs` before dereferencing it to access its`isLocal` method.
rdar://67410058
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch relands commit 3e3e79a9e4, 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 <medismail.bennani@gmail.com>
This patch should fix the test failure on scripted_crashlog_json.test.
The failure is happening because crash reporter will obfuscate the
executable path in the crashlog, if it is located inside the user's
home directory and replace it with `/USER/*/` as a placeholder.
To fix that, we can patch the placeholder with the executable path
before loading the crashlog in lldb.
This also fixes a bug where we would create another target when loading
the crashlog in a scripted process, even if lldb already had a target
for it. Now, crashlog will only create a target if there is none in lldb.
Differential Revision: https://reviews.llvm.org/D120598
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Instead of checking whether TARGET_OS_IPHONE is set to 1, the current
code just check the existence of TARGET_OS_IPHONE, which either always
succeeds or always fails, depending on whether you have
TargetConditionals.h included.
In the changes Jonas made in https://reviews.llvm.org/D117340 , a
small oversight was that PlatformMacOSX (despite the name) is active
for any native Darwin operating system, where lldb and the target
process are running on the same system. This patch uses compile-time
checks to return the appropriate OSType for the OS lldb is being
compiled to, so the "host" platform will correctly be selected when
lldb & the inferior are both running on that OS. And a small change
to PlatformMacOSX::GetSupportedArchitectures which adds additional
recognized triples when running on macOS but not other native Darwin
systems.
Differential Revision: https://reviews.llvm.org/D120517
rdar://89247060
All current callers set the argument to false. monitor_signals=true used
to be used in the Process plugins (which needed to know when the
debugged process gets a signal), but this implementation has several
serious issues, which means that individual process plugins now
orchestrate the monitoring of debugged processes themselves.
This allows us to simplify the implementation (no need to play with
process groups), and the interface (we only catch fatal events, so the
callback is always called just once).
Differential Revision: https://reviews.llvm.org/D120425
This patch is a follow-up of D120100 to address some feedbacks from
@labath.
This should mainly fix the race issue with the even listener by moving
the listener setup to the main thread.
This also changes the SBDebugger::GetProgressFromEvent SWIG binding
arguments to be output only, so the user don't have to provide them.
Finally, this updates the test to check it the out arguments are returned
in a tuple and re-enables the test on all platforms.
Differential Revision: https://reviews.llvm.org/D120284
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Jim noticed that the regex command is unintentionally recursive. Let's
use the following command regex as an example:
(lldb) com regex humm 's/([^ ]+) ([^ ]+)/p %1 %2 %1 %2/'
If we call it with arguments foo bar, thing behave as expected:
(lldb) humm foo bar
(...)
foo bar foo bar
However, if we include %2 in the arguments, things break down:
(lldb) humm fo%2o bar
(...)
fobaro bar fobaro bar
The problem is that the implementation of the substitution is too naive.
It substitutes the %1 token into the target template in place, then does
the %2 substitution starting with the resultant string. So if the
previous substitution introduced a %2 token, it would get processed in
the second sweep, etc.
This patch addresses the issue by walking the command once and
substituting the % variables in place.
(lldb) humm fo%2o bar
(...)
fo%2o bar fo%2o bar
Furthermore, this patch also reports an error if not enough variables
were provided and add support for substituting %0.
rdar://81236994
Differential revision: https://reviews.llvm.org/D120101
The class is using an incredibly elaborate setup to create and destroy
an NSAutoreleasePool object. We can do it in a much simpler way by
making those calls inside our thread startup function.
The only effect of this patch is that the pool gets released at the end
of the ThreadCreateTrampoline function, instead of slightly later, when
pthreads begin thread-specific cleanup. However, the key destruction
order is unspecified, so nothing should be relying on that.
I didn't find a specific reason for why this would have to be done that
way in git history. It seems that before D5198, this was thread-specific
keys were the only way an os implementation (in Host::ThreadCreated)
could attach some value to a thread.
Differential Revision: https://reviews.llvm.org/D120322
Accept a function object instead of a raw pointer. This avoids a bunch
of boilerplate typically needed to pass arguments to the thread
functions.
Differential Revision: https://reviews.llvm.org/D120321
The race is between these two pieces of code that are executed in two separate
lldb-vscode threads (the first is in the main thread and another is in the
event-handling thread):
```
// lldb-vscode.cpp
g_vsc.debugger.SetAsync(false);
g_vsc.target.Launch(launch_info, error);
g_vsc.debugger.SetAsync(true);
```
```
// Target.cpp
bool old_async = debugger.GetAsyncExecution();
debugger.SetAsyncExecution(true);
debugger.GetCommandInterpreter().HandleCommands(GetCommands(), exc_ctx,
options, result);
debugger.SetAsyncExecution(old_async);
```
The sequence that leads to the bug is this one:
1. Main thread enables synchronous mode and launches the process.
2. When the process is launched, it generates the first stop event.
3. This stop event is catched by the event-handling thread and DoOnRemoval
is invoked.
4. Inside DoOnRemoval, this thread runs stop hooks. And before running stop
hooks, the current synchronization mode is stored into old_async (and
right now it is equal to "false").
5. The main thread finishes the launch and returns to lldb-vscode, the
synchronization mode is restored to asynchronous by lldb-vscode.
6. Event-handling thread finishes stop hooks processing and restores the
synchronization mode according to old_async (i.e. makes the mode synchronous)
7. And now the mode is synchronous while lldb-vscode expects it to be
asynchronous. Synchronous mode forbids the process to broadcast public stop
events, so, VS Code just hangs because lldb-vscode doesn't notify it about
stops.
So, this diff makes the target intercept the first stop event if the process is
launched in the synchronous mode, thus preventing stop hooks execution.
The bug is only present on Windows because other platforms already
intercept this event using their own hijacking listeners.
So, this diff also fixes some problems with lldb-vscode tests on Windows to make
it possible to run the related test. Other tests still can't be enabled because
the debugged program prints something into stdout and LLDB can't intercept this
output and redirect it to lldb-vscode properly.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D119548
In C++20 modules imports must be together and at the start of the module.
Rather than growing more ad-hoc flags to test state, this keeps track of the
phase of of a valid module TU (first decl, global module frag, module,
private module frag). If the phasing is broken (with some diagnostic) the
pattern does not conform to a valid C++20 module, and we set the state
accordingly.
We can thus issue diagnostics when imports appear in the wrong places and
decouple the C++20 modules state from other module variants (modules-ts and
clang modules). Additionally, we attempt to diagnose wrong imports before
trying to find the module where possible (the latter will generally emit an
unhelpful diagnostic about the module not being available).
Although this generally simplifies the handling of C++20 module import
diagnostics, the motivation was that, in particular, it allows detecting
invalid imports like:
import module A;
int some_decl();
import module B;
where being in a module purview is insufficient to identify them.
Differential Revision: https://reviews.llvm.org/D118893
This patch defines the SBDebugger::eBroadcastBitProgress enum in the SWIG
interface and exposes the SBDebugger::{GetProgressFromEvent,GetBroadcaster}
methods as well.
This allows to exercise the API from the script interpreter using python.
Differential Revision: https://reviews.llvm.org/D120100
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
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
We discovered that when using "launchCommands" or "attachCommands" that there was an issue where these commands were not being run synchronously. There were further problems in this case where we would get thread events for the process that was just launched or attached before the IDE was ready, which is after "configurationDone" was sent to lldb-vscode.
This fix introduces the ability to wait for the process to stop after the run or attach to ensure that we have a stopped process at the entry point that is ready for the debug session to proceed. This also allows us to run the normal launch or attach without needing to play with the async flag the debugger. We spin up the thread that listens for process events before we start the launch or attach, but we stop the first eStateStopped (with stop ID of zero) event from being delivered through the DAP protocol because the "configurationDone" request handler will deliver it manually as the IDE expects a stop after configuration done. The request_configurationDone will also only deliver the stop packet if the "stopOnEntry" is False in the launch configuration.
Also added a new "timeout" to the launch and attach launch configuration arguments that can be set and defaults to 30 seconds. Since we now poll to detect when the process is stopped, we need a timeout that can be changed in case certain workflows take longer that 30 seconds to attach. If the process is not stopped by the timeout, an error will be retured for the launch or attach.
Added a flag to the vscode.py protocol classes that detects and ensures that no "stopped" events are sent prior to "configurationDone" has been sent and will raise an error if it does happen.
This should make our launching and attaching more reliable and avoid some deadlocks that were being seen (https://reviews.llvm.org/D119548).
Differential Revision: https://reviews.llvm.org/D119797
Currently we are not emitting debug-info for all cases of structured bindings a
C++17 feature which allows us to bind names to subobjects in an initializer.
A structured binding is represented by a DecompositionDecl AST node and the
binding are represented by a BindingDecl. It looks the original implementation
only covered the tuple like case which be represented by a DeclRefExpr which
contains a VarDecl.
If the binding is to a subobject of the struct the binding will contain a
MemberExpr and in the case of arrays it will contain an ArraySubscriptExpr.
This PR adds support emitting debug-info for the MemberExpr and ArraySubscriptExpr
cases as well as llvm and lldb tests for these cases as well as the tuple case.
Differential Revision: https://reviews.llvm.org/D119178
This patch adds requirement for the `scripted_crashlog_json` test to
make sure it only runs on apple silicon systems.
This should fix the following green dragon failure:
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/41454
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Identifiers with __ anywhere are reserved. I picked this up via the
bugprone-reserved-identifier clang-tidy check but -Wreserved-identifier will
also flag these uses as well.
Differential Revision: https://reviews.llvm.org/D119915
In some cases, it can happen that crashlogs don't have any signal in
the exception, which causes the parser to crash.
This fixes the parsing by checking if the `signal` field is in the
`exception` dictionary before trying to access it.
rdar://84552251
Differential Revision: https://reviews.llvm.org/D119504
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch introduces a new type of ScriptedProcess: CrashLogScriptedProcess.
It takes advantage of lldb's crashlog parsers and Scripted Processes to
reconstruct a static debugging session with symbolicated stackframes, instead
of just dumping out everything in the user's terminal.
The crashlog command also has an interactive mode that only provide a
very limited experience. This is why this patch removes all the logic
for this interactive mode and creates CrashLogScriptedProcess instead.
This will fetch and load all the libraries that were used by the crashed
thread and re-create all the frames artificially.
rdar://88721117
Differential Revision: https://reviews.llvm.org/D119501
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds the ability for the user to check if the command
interpreter's IOHandler is interactive.
Differential Revision: https://reviews.llvm.org/D119499
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds the ability for ScriptedThread to load artificial stack
frames. To do so, the interpreter instance can create a list that will
contain the frame index and its pc address.
Then, when the Scripted Process plugin stops, it will refresh its
Scripted Threads state by invalidating their register context and load
to list from the interpreter object and reconstruct each frame.
This patch also removes all of the default implementation for
`get_stackframes` from the derived ScriptedThread classes, and add the
interface code for the Scripted Thread Interface.
rdar://88721095
Differential Revision: https://reviews.llvm.org/D119388
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch removes the `my_scripted_process.py` blueprint since it's not
used anymore.
The patch also updates the base ScriptedProcess and ScriptedThread
initializers to automatically initialize convinience variables, to
access debugger from the ScriptedProcess, access the SBProcess and
ScriptedProcess object from a ScriptedThread instance.
Differential Revision: https://reviews.llvm.org/D119386
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
- Use an early return.
- Check for error.Fail() instead of !error.Success().
- Check the resolver pointer before using instead of relying on the
error being set.
Jonas Devlieghere