The old command wrote to CWD, which doesn't always work, and if it
didn't, there was no workaround (and it crashed on failure). This
patch changed the setting to provide a directory to save the objects
to.
Differential Revision: https://reviews.llvm.org/D121036
Support ANSI escape codes for bright colors variants. Most modern
terminals support them. LLDB is not using them in any of its defaults,
but they're useful for people who want to modify their preferred ANSI
prefix/suffix.
Differential revision: https://reviews.llvm.org/D121131
This improves this test a lot because before when using the "attachCommands" to run the following commands:
(lldb) target create -d /path/to/a.out
(lldb) process launch
This was racy as it wasn't stopping the program at the entry point, and the process might run to completion before we can even debug it. With the recent changes to the "attachCommands" we were waiting for the process to stop, but the process might be exited already, and that _should_ have caused the attach to fail since there was no process to attach to. By adding "--stop-at-entry" to the process launch, we ensure this should be less racy and give us a valid process to attach to.
I'm a big fan of the autosuggestion feature but my terminal/color scheme
doesn't display faint any differently than regular lldb output, which
makes the feature a little confusing. This patch add a setting to change
the autosuggestion ANSI escape codes.
For example, to display the autosuggestion in italic, you can add this
to your ~/.lldbinit
settings set show-autosuggestion-ansi-prefix ${ansi.italic}
setting set show-autosuggestion-ansi-suffix ${ansi.normal}
Differential revision: https://reviews.llvm.org/D121064
This disables TestScriptedProcess.test_scripted_process_and_scripted_thread
on Windows since the inferior binary a linked to a dylib that doesn't
build on Windows.
This should fix https://lab.llvm.org/buildbot/#/builders/83/builds/16100
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch introduces a new way to load modules programatically with
Scripted Processes. To do so, the scripted process blueprint holds a
list of dictionary describing the modules to load, which their path or
uuid, load address and eventually a slide offset.
LLDB will fetch that list after launching the ScriptedProcess, and
iterate over each entry to create the module that will be loaded in the
Scripted Process' target.
The patch also refactors the StackCoreScriptedProcess test to stop
inside the `libbaz` module and make sure it's loaded correctly and that
we can fetch some variables from it.
rdar://74520238
Differential Revision: https://reviews.llvm.org/D120969
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch replaces the calls to ErrorWithMessage using the GetInterface
message by a call to the static method directly.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch re-enables TestEvents.py on Darwin and fixes some crashes
that were happening due to an undefined method.
I ran it 100 times locally with the following command and it passed
every the time:
```
for i in {1..100}; do print $i/100; ./bin/lldb-dotest -p TestEvents.py 2>&1 | rg PASSED; if [ "$?" -eq "1" ]; then break; fi; done
```
Let's see if it still fails non-deterministically on the bots and
eventually also re-enable it on linux.
rdar://37037235
Differential Revision: https://reviews.llvm.org/D120607
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This is a modified version of a previous patch that was reverted: https://reviews.llvm.org/D119797
This version only waits for the process to stop when using "launchCommands" or "attachCommands"...
...and doesn't play with the async mode when doing normal launch/attach.
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 "launchCommands" or "attachCommands" are run to ensure that we have a stopped process point that is ready for the debug session to proceed. We spin up the thread that listens for process events before we start the launch or attach, but we don't want stop events being delivered through the DAP protocol until the "configurationDone" packet is received. We now always ignore the stop event with a stop ID of 1, which is the first stop. All normal launch and attach scenarios use the synchronous mode, and "launchCommands and "attachCommands" run an array of LLDB commands in async mode.
This should make our launch with "launchCommands" and attach with "attachCommands" avoid a race condition when the process is being launched or attached.
Differential Revision: https://reviews.llvm.org/D120755
This patch removes the ability to instantiate the LLDB FileSystem class
with a FileCollector. It keeps the ability to collect files, but uses
the FileCollectorFileSystem to do that transparently.
Because the two are intertwined, this patch also removes the
finalization logic which copied the files over out of process.
1) Make the BreakpointEventData::Dump actually do something useful.
2) Make the Breakpoint events print when the break log channel is on
without having to turn on the events channel.
Differential Revision: https://reviews.llvm.org/D120917
This patch removes the ability to instantiate the LLDB FileSystem class
based on a VFS overlay. This also removes the "hack" where we cast the
VFS to a RedirectingFileSystem to obtain the external path. You can
still instantiate a FileSystem with a VFS, but with the caveat that
operations that rely on the external path won't work.
Differential revision: https://reviews.llvm.org/D120923
We have using namespace llvm::dwarf in dwarf.h header globally. Replacing that
with a using namespace within lldb_private::dwarf and moving to a
using namespace lldb_private::dwarf in .cpp files and fully qualified names
in the few header files.
Differential Revision: https://reviews.llvm.org/D120836
This reverts commit 6b3b3ef344.
Jim Ingham informed me that the upper case is a hint to the option
name, like you might see in a menu to show you what the shortcut is.
There are two DataExtractors in scope: one from the llvm namespace and
one from the lldb_private namespace. Some Microsoft Visual C++ compilers
(I tested with MSVC 14.23 specifically) cannot handle this situation,
and generate ambiguous symbol errors. This change fixes this compile
error.
Differential revision: https://reviews.llvm.org/D120718
The check for the prompt isn't essential for this test. The check fail
on the lldb-arm-ubuntu because of what appears to be a missing space
after the prompt. Rather than disabling the test, let's see if we can
get it to pass without it.
This patch fixes a data race in IOHandlerProcessSTDIO. The race is
happens between the main thread and the event handling thread. The main
thread is running the IOHandler (IOHandlerProcessSTDIO::Run()) when an
event comes in that makes us pop the process IO handler which involves
cancelling the IOHandler (IOHandlerProcessSTDIO::Cancel). The latter
calls SetIsDone(true) which modifies m_is_done. At the same time, we
have the main thread reading the variable through GetIsDone().
This patch avoids the race by using a mutex to synchronize the two
threads. On the event thread, in IOHandlerProcessSTDIO ::Cancel method,
we obtain the lock before changing the value of m_is_done. On the main
thread, in IOHandlerProcessSTDIO::Run(), we obtain the lock before
reading the value of m_is_done. Additionally, we delay calling SetIsDone
until after the loop exists, to avoid a potential race between the two
writes.
Write of size 1 at 0x00010b66bb68 by thread T7 (mutexes: write M2862, write M718324145051843688):
#0 lldb_private::IOHandler::SetIsDone(bool) IOHandler.h:90 (liblldb.15.0.0git.dylib:arm64+0x971d84)
#1 IOHandlerProcessSTDIO::Cancel() Process.cpp:4382 (liblldb.15.0.0git.dylib:arm64+0x5ddfec)
#2 lldb_private::Debugger::PopIOHandler(std::__1::shared_ptr<lldb_private::IOHandler> const&) Debugger.cpp:1156 (liblldb.15.0.0git.dylib:arm64+0x3cb2a8)
#3 lldb_private::Debugger::RemoveIOHandler(std::__1::shared_ptr<lldb_private::IOHandler> const&) Debugger.cpp:1063 (liblldb.15.0.0git.dylib:arm64+0x3cbd2c)
#4 lldb_private::Process::PopProcessIOHandler() Process.cpp:4487 (liblldb.15.0.0git.dylib:arm64+0x5c583c)
#5 lldb_private::Debugger::HandleProcessEvent(std::__1::shared_ptr<lldb_private::Event> const&) Debugger.cpp:1549 (liblldb.15.0.0git.dylib:arm64+0x3ceabc)
#6 lldb_private::Debugger::DefaultEventHandler() Debugger.cpp:1622 (liblldb.15.0.0git.dylib:arm64+0x3cf2c0)
#7 std::__1::__function::__func<lldb_private::Debugger::StartEventHandlerThread()::$_2, std::__1::allocator<lldb_private::Debugger::StartEventHandlerThread()::$_2>, void* ()>::operator()() function.h:352 (liblldb.15.0.0git.dylib:arm64+0x3d1bd8)
#8 lldb_private::HostNativeThreadBase::ThreadCreateTrampoline(void*) HostNativeThreadBase.cpp:62 (liblldb.15.0.0git.dylib:arm64+0x4c71ac)
#9 lldb_private::HostThreadMacOSX::ThreadCreateTrampoline(void*) HostThreadMacOSX.mm:18 (liblldb.15.0.0git.dylib:arm64+0x29ef544)
Previous read of size 1 at 0x00010b66bb68 by main thread:
#0 lldb_private::IOHandler::GetIsDone() IOHandler.h:92 (liblldb.15.0.0git.dylib:arm64+0x971db8)
#1 IOHandlerProcessSTDIO::Run() Process.cpp:4339 (liblldb.15.0.0git.dylib:arm64+0x5ddc7c)
#2 lldb_private::Debugger::RunIOHandlers() Debugger.cpp:982 (liblldb.15.0.0git.dylib:arm64+0x3cb48c)
#3 lldb_private::CommandInterpreter::RunCommandInterpreter(lldb_private::CommandInterpreterRunOptions&) CommandInterpreter.cpp:3298 (liblldb.15.0.0git.dylib:arm64+0x506478)
#4 lldb::SBDebugger::RunCommandInterpreter(bool, bool) SBDebugger.cpp:1166 (liblldb.15.0.0git.dylib:arm64+0x53604)
#5 Driver::MainLoop() Driver.cpp:634 (lldb:arm64+0x100006294)
#6 main Driver.cpp:853 (lldb:arm64+0x100007344)
Differential revision: https://reviews.llvm.org/D120762
This allows `image lookup -a ... -v` to print variables only if the given
address is covered by the valid ranges of the variables. Since variables created
in dwarf plugin always has empty scope range, print the variable if it has
empty scope.
Differential Revision: https://reviews.llvm.org/D119963
The upstream project ships CMake rules for building vanilla gtest/gmock which conflict with the names chosen by LLVM. Since LLVM's build rules here are quite specific to LLVM, prefixing them to avoid collision is the right thing (i.e. there does not appear to be a path to letting someone *replace* LLVM's googletest with one they bring, so co-existence should be the goal).
This allows LLVM to be included with testing enabled within projects that themselves have a dependency on an official gtest release.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D120789
This patch changes the return value of Platform::GetName() to a
StringRef, and uses the opportunity (compile errors) to change some
callsites to use GetPluginName() instead. The two methods still remain
hardwired to return the same thing, but this will change once the ideas
in
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>
are implemented.
Differential Revision: https://reviews.llvm.org/D119146
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.
After applying the same for as in TestThreadBacktraceRepeat, the test
appears to pass reliably. The skip decorator was added many years ago,
so it's not clear whether this is what caused it to hang.
D115300 added Rust as a new PDB language type.
This change allows LLDB to recognize the new language type.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D119044
I was looking at Stream::PutRawBytes and thought I spotted a bug because
both loops are using `i < src_len` as the loop condition despite them
iterating in opposite directions.
On closer inspection, the existing code is correct, because it relies on
well-defined unsigned integer wrapping. Correct doesn't mean readable,
so this patch changes the loop condition to compare against 0 when
decrementing i while still covering the edge case of src_len potentially
being 0 itself.
Differential revision: https://reviews.llvm.org/D119857
Don't resize DataBufferHeap if the newly requested size exceeds the
capacity of the underlying data structure, i.e. std::vector<uint8_t>.
This matches the existing check in the DataBufferHeap constructor.
As usual with that header cleanup series, some implicit dependencies now need to
be explicit:
llvm/DebugInfo/DWARF/DWARFContext.h no longer includes:
- "llvm/DebugInfo/DWARF/DWARFAcceleratorTable.h"
- "llvm/DebugInfo/DWARF/DWARFCompileUnit.h"
- "llvm/DebugInfo/DWARF/DWARFDebugAbbrev.h"
- "llvm/DebugInfo/DWARF/DWARFDebugAranges.h"
- "llvm/DebugInfo/DWARF/DWARFDebugFrame.h"
- "llvm/DebugInfo/DWARF/DWARFDebugLoc.h"
- "llvm/DebugInfo/DWARF/DWARFDebugMacro.h"
- "llvm/DebugInfo/DWARF/DWARFGdbIndex.h"
- "llvm/DebugInfo/DWARF/DWARFSection.h"
- "llvm/DebugInfo/DWARF/DWARFTypeUnit.h"
- "llvm/DebugInfo/DWARF/DWARFUnitIndex.h"
Plus llvm/Support/Errc.h not included by a bunch of llvm/DebugInfo/DWARF/DWARF*.h files
Preprocessed lines to build llvm on my setup:
after: 1065629059
before: 1066621848
Which is a great diff!
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D119723
lldb reports (and lldbutil.continue_to_breakpoint returns) a stop reason
even for suspended threads. Fix the test to expect that.
This was making the test flaky, as most of the time, the two threads
stop simultaneously, and the synchronization code is not executed.
The symbolicator assumes that the first image in the image list is the
main image. That isn't always the case. For JSON crashlogs we can use
the procName to move the main image to the front of the list.
rdar://83907760
One of the tests in this test setup was copied from a more complex test, and I didn't know
if the setup or the subsequent parts of the test were the ones that fail on Linux. Looks
like it was the latter, so let's mark this succeeding.
Some dyld cross library stubs can have line information but no function. Make sure you
check that you have a valid Function object before asking it questions.
Differential Revision: https://reviews.llvm.org/D119297
This way if you have a long stack, you can issue "thread backtrace --count 10"
and then subsequent <Return>-s will page you through the stack.
This took a little more effort than just adding the repeat command, since
the GetRepeatCommand API was returning a "const char *". That meant the command
had to keep the repeat string alive, which is inconvenient. The original
API returned either a nullptr, or a const char *, so I changed the private API to
return an llvm::Optional<std::string>. Most of the patch is propagating that change.
Also, there was a little thinko in fetching the repeat command. We don't
fetch repeat commands for commands that aren't being added to history, which
is in general reasonable. And we don't add repeat commands to the history -
also reasonable. But we do want the repeat command to be able to generate
the NEXT repeat command. So I adjusted the logic in HandleCommand to work
that way.
Differential Revision: https://reviews.llvm.org/D119046
Instead trying to pro-actively determine if the first line in a
crashlog contains meta data, change the heuristic to do the following:
1. To trying to parse the whole file. If that fails, then:
2. Strip the first line and try parsing the remainder of the file. If
that fails, then:
3. Fall back to the textual crashlog parser.
rdar://88580543
Differential revision: https://reviews.llvm.org/D119755
ObjectFileMachO, for a couple of special binaries at the initial
launch, needs to find segment load addresses before the Target's
SectionLoadList has been initialized. The calculation to find
the first segment, which is at the same address as the mach header,
was not correct if the binary was in the Darwin shared cache.
Update the logic to handle that case.
Differential Revision: https://reviews.llvm.org/D119602
rdar://88802629
The IR interpreter supports const operands to the `GetElementPtr` IR
instruction, so it should be able to evaluate expression without JIT.
Follow up to https://reviews.llvm.org/D113498
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D119734
The current dectorator (@skipIfLinux) will skip the test if the lldb
platform is the linux platform, but the issue is with the OS that lldb
is running on, not the OS that lldb is debugging. Update the decorator
to skip the test if the host is Linux.
Thank you Ted Woodward for pointing this out.
Recently we observed high memory pressure caused by clang during some parallel builds.
We discovered that we have several projects that have a large number of #define directives
in their TUs (on the order of millions), which caused huge memory consumption in clang due
to a lot of allocations for MacroInfo. We would like to reduce the memory overhead of
clang for a single #define to reduce the memory overhead for these files, to allow us to
reduce the memory pressure on the system during highly parallel builds. This change achieves
that by removing the SmallVector in MacroInfo and instead storing the tokens in an array
allocated using the bump pointer allocator, after all tokens are lexed.
The added unit test with 1000000 #define directives illustrates the problem. Prior to this
change, on arm64 macOS, clang's PP bump pointer allocator allocated 272007616 bytes, and
used roughly 272 bytes per #define. After this change, clang's PP bump pointer allocator
allocates 120002016 bytes, and uses only roughly 120 bytes per #define.
For an example test file that we have internally with 7.8 million #define directives, this
change produces the following improvement on arm64 macOS: Persistent allocation footprint for
this test case file as it's being compiled to LLVM IR went down 22% from 5.28 GB to 4.07 GB
and the total allocations went down 14% from 8.26 GB to 7.05 GB. Furthermore, this change
reduced the total number of allocations made by the system for this clang invocation from
1454853 to 133663, an order of magnitude improvement.
The recommit fixes the LLDB build failure.
Differential Revision: https://reviews.llvm.org/D117348
Replace forms of `assertTrue(err.Success())` with `assertSuccess(err)` (added in D82759).
* `assertSuccess` prints out the error's message
* `assertSuccess` expresses explicit higher level semantics, both to the reader and for test failure output
* `assertSuccess` seems not to be well known, using it where possible will help spread knowledge
* `assertSuccess` statements are more succinct
Differential Revision: https://reviews.llvm.org/D119616
This mainly affects Darwin targets (macOS, iOS, tvOS and watchOS) when these targets don't use dSYM files and the debug info was in the .o files. All modules, including the .o files that are loaded by the debug maps, were in the global module list. This was great because it allows us to see each .o file and how much it contributes. There were virtual functions on the SymbolFile class to fetch the symtab/debug info parse and index times, and also the total debug info size. So the main executable would add all of the .o file's stats together and report them as its own data. Then the "totalDebugInfoSize" and many other "totalXXX" top level totals were all being added together. This stems from the fact that my original patch only emitted the modules for a target at the start of the patch, but as comments from the reviews came in, we switched to emitting all of the modules from the global module list.
So this patch fixes it so when we have a SymbolFileDWARFDebugMap that loads .o files, the main executable will have no debug info size or symtab/debug info parse/index times, but each .o file will have its own data as a separate module. Also, to be able to tell when/if we have a dSYM file I have added a "symbolFilePath" if the SymbolFile for the main modules path doesn't match that of the main executable. We also include a "symbolFileModuleIdentifiers" key in each module if the module does have multiple lldb_private::Module objects that contain debug info so that you can track down the information for a module and add up the contributions of all of the .o files.
Tests were added that are labeled with @skipUnlessDarwin and @no_debug_info_test that test all of this functionality so it doesn't regress.
For a module with a dSYM file, we can see the "symbolFilePath" is included:
```
"modules": [
{
"debugInfoByteSize": 1070,
"debugInfoIndexLoadedFromCache": false,
"debugInfoIndexSavedToCache": false,
"debugInfoIndexTime": 0,
"debugInfoParseTime": 0,
"identifier": 4873280600,
"path": "/Users/gclayton/Documents/src/lldb/main/Debug/lldb-test-build.noindex/commands/statistics/basic/TestStats.test_dsym_binary_has_symfile_in_stats/a.out",
"symbolFilePath": "/Users/gclayton/Documents/src/lldb/main/Debug/lldb-test-build.noindex/commands/statistics/basic/TestStats.test_dsym_binary_has_symfile_in_stats/a.out.dSYM/Contents/Resources/DWARF/a.out",
"symbolTableIndexTime": 7.9999999999999996e-06,
"symbolTableLoadedFromCache": false,
"symbolTableParseTime": 7.8999999999999996e-05,
"symbolTableSavedToCache": false,
"triple": "arm64-apple-macosx12.0.0",
"uuid": "E1F7D85B-3A42-321E-BF0D-29B103F5F2E3"
},
```
And for the DWARF in .o file case we can see the "symbolFileModuleIdentifiers" in the executable's module stats:
```
"modules": [
{
"debugInfoByteSize": 0,
"debugInfoIndexLoadedFromCache": false,
"debugInfoIndexSavedToCache": false,
"debugInfoIndexTime": 0,
"debugInfoParseTime": 0,
"identifier": 4603526968,
"path": "/Users/gclayton/Documents/src/lldb/main/Debug/lldb-test-build.noindex/commands/statistics/basic/TestStats.test_no_dsym_binary_has_symfile_identifiers_in_stats/a.out",
"symbolFileModuleIdentifiers": [
4604429832
],
"symbolTableIndexTime": 7.9999999999999996e-06,
"symbolTableLoadedFromCache": false,
"symbolTableParseTime": 0.000112,
"symbolTableSavedToCache": false,
"triple": "arm64-apple-macosx12.0.0",
"uuid": "57008BF5-A726-3DE9-B1BF-3A9AD3EE8569"
},
```
And the .o file for 4604429832 looks like:
```
{
"debugInfoByteSize": 1028,
"debugInfoIndexLoadedFromCache": false,
"debugInfoIndexSavedToCache": false,
"debugInfoIndexTime": 0,
"debugInfoParseTime": 6.0999999999999999e-05,
"identifier": 4604429832,
"path": "/Users/gclayton/Documents/src/lldb/main/Debug/lldb-test-build.noindex/commands/statistics/basic/TestStats.test_no_dsym_binary_has_symfile_identifiers_in_stats/main.o",
"symbolTableIndexTime": 0,
"symbolTableLoadedFromCache": false,
"symbolTableParseTime": 0,
"symbolTableSavedToCache": false,
"triple": "arm64-apple-macosx"
}
```
Differential Revision: https://reviews.llvm.org/D119400
This reverts commit 0df522969a.
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
This patch fixes the register parser for arm64 crashlogs.
Compared to x86_64 crashlogs, the arm64 crashlogs nests the general
purpose registers into a separate dictionary within `thread_state`
dictionary. It uses the dictionary key as the the register number.
Differential Revision: https://reviews.llvm.org/D119168
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This splits the scripted process tests to be able to run in parallel
since some of test functions can take a very long time to run.
This also disables debug info testing.
Differential Revision: https://reviews.llvm.org/D118513
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch fixes a timeout issue on the ScriptedProcess test that was
happening on intel platforms. The timeout was due to a misreporting of
the StopInfo in the ScriptedThread that caused the ScriptedProcess to
never stop.
To solve this, this patch changes the way a ScriptedThread reports its
stop reason by making it more architecture specific. In order to do so,
this patch also refactors the ScriptedProcess & ScriptedThread
initializer methods to provide an easy access to the target architecture.
Differential Revision: https://reviews.llvm.org/D118484
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
After 9611282c, TestGdbRemoteThreadsInStopReply is not non-deterministic
-- instead it deterministically fails due to extra threads created by
std::thread thread pool.
Adjust the tests to account for that.
Operands to `getelementptr` can be constants or constant expressions. Check
that all operands can be constant-resolved and resolve them during the
evaluation. If some operands can't be resolved as constants -- the expression
evaluation will fallback to JIT.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=52449
Reviewed By: #lldb, shafik
Differential Revision: https://reviews.llvm.org/D113498
The tests enabled in 9e699595 are not passing reliably -- sometimes they
report seeing fewer threads than expected.
Based on my (limited) research, this is not a lldb bug, but simply a
consequence of the operating system reporting their presence
asynchronously -- they're reported when they are scheduled to run (or
something similar), and not at the time of the CreateThread call.
To fix this, I add some additional synchronization to the test inferior,
which makes sure that the created thread is alive before continuing to
do other things.
This patch updates toolchain-msvc.test to cater for Arm64 windows platform.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D117676
D119167 changed the meaning of that test by removing the use of the
interrupt packet. I did not notice this because the interrupting
happened in a shared utility function.
This patch restores the original meaning of the test, but (almost)
avoids sleeps by using process stdout to synchronize. Sadly, this means
the test stays disabled on windows, as it does not implement output
forwarding.
A couple of additional tests pass with that patch. One new test fails
(because it's not testing a slightly different thing). I'll update it
later to restore the original meaning (I don't want to revert as the net
effect is still very positive), but for now this gets the bot green.
Instead of using sleeps, have the inferior notify us (via a trap opcode) that
the requested number of threads have been created.
This allows us to get rid of some fairly dodgy test utility code --
wait_for_thread_count seemed like it was waiting for the threads to
appear, but it never actually let the inferior run, so it only succeeded
if the threads were already started when the function was called. Since
the function was called after a fairly small delay (1s, usually), this
is probably the reason why the tests were failing on some bots.
Differential Revision: https://reviews.llvm.org/D119167
Major user-facing changes:
Many headers in llvm/DebugInfo/CodeView no longer include
llvm/Support/BinaryStreamReader.h or llvm/Support/BinaryStreamWriter.h,
those headers may need to be included manually.
Several headers in llvm/DebugInfo/CodeView no longer include
llvm/DebugInfo/CodeView/EnumTables.h or llvm/DebugInfo/CodeView/CodeView.h,
those headers may need to be included manually.
Some statistics:
$ clang++ -E -Iinclude -I../llvm/include ../llvm/lib/DebugInfo/CodeView/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
after: 2794466
before: 2832765
Discourse thread on the topic: https://discourse.llvm.org/t/include-what-you-use-include-cleanup/
Differential Revision: https://reviews.llvm.org/D119092
Reviewing some recent fixes to the platform packet implementations
in lldb, I saw the docs were out of sync in a few spots. Updated them.
Differential Revision: https://reviews.llvm.org/D118842
When LLVM_ENABLE_ZLIB is ON gdb-remote should link against ZLIB::ZLIB.
This fixes
```
/mnt/b/yoe/master/build/tmp/hosttools/ld: lib/liblldbPluginProcessGDBRemote.a(GDBRemoteCommunication.cpp.o): in function `lldb_private::process_gdb_remote::GDBRemoteCommunication::DecompressPacket() [clone .localalias]':
GDBRemoteCommunication.cpp:(.text._ZN12lldb_private18process_gdb_remote22GDBRemoteCommunication16DecompressPacketEv+0x59a): undefined reference to `inflateInit2_'
/mnt/b/yoe/master/build/tmp/hosttools/ld: GDBRemoteCommunication.cpp:(.text._ZN12lldb_private18process_gdb_remote22GDBRemoteCommunication16DecompressPacketEv+0x5af): undefined reference to `inflate'
```
Reviewed By: JDevlieghere, MaskRay
Differential Revision: https://reviews.llvm.org/D119186
Update `__init__.py` generation to implement `__lldb_init_module`, which calls
`__lldb_init_module` on submodules that define it.
This allows the use case where a user runs `command script import lldb.macosx`.
With this change, the `__lldb_init_module` function in `crashlog.py` and
`heap.py` will be run, which is where command registration is occurring.
Differential Revision: https://reviews.llvm.org/D119179
Previously, importing `crashlog` resulted in a message being printed. The
message was about other commands (those in heap.py), not `crashlog`. The
changes in D117237 made it so that the heap.py messages were printed only when
importing `lldb.macosx.heap`, not when importing `lldb.macosx.crashlog`. Some
users may see no output and think `crashlog` wasn't successfully loaded. This
ensures users see that `crashlog` is loaded.
rdar://88283132
Differential Revision: https://reviews.llvm.org/D119155
As Pavel pointed out, on Apple Silicon "b main" stops at a point after
the variable has already been initialized. This patch updates the test
case to avoids that. I've also split the test into separate files so its
easier to reproduce the individual scenarios without having to build any
shared state.
This fixes TestGdbRemoteSingleStep.py and TestGdbRemote_vCont.py. This
patch updates the test to account for the possibility that the constants
are already materialized. This appears to behave differently between
embedded arm64 devices and Apple Silicon.
After aed965d55d we no longer demangle and store the full name. The
test was updated accordingly but the comment still specified that we
should be able to find the symbol by its full demangled name.
After aed965d we no longer demangle full symbol names while indexing the
symbol table which means we have to use the mangled name instead of the
demangled name to find the symbol for __asan::AsanDie().
This fixes the following two tests:
lldb-api :: functionalities/asan/TestMemoryHistory.py
lldb-api :: functionalities/asan/TestReportData.py
iOS systems are getting near this limit; double itfrom a 150kb
buffer to a 300kb buffer, which is freed after processing the
list of classes.
rdar://88454594
Differential Revision: https://reviews.llvm.org/D118972
The symbol table needs to demangle all symbol names when building its
index. However, this doesn't require the full mangled name: we only need
the base name and the function declaration context. Currently, we always
construct the demangled string during indexing and cache it in the
string pool as a way to speed up future lookups.
Constructing the demangled string is by far the most expensive step of
the demangling process, because the output string can be exponentially
larger than the input and unless you're dumping the symbol table, many
of those demangled names will not be needed again.
This patch avoids constructing the full demangled string when we can
partially demangle. This speeds up indexing and reduces memory usage.
I gathered some numbers by attaching to Slack:
Before
------
Memory usage: 280MB
Benchmark 1: ./bin/lldb -n Slack -o quit
Time (mean ± σ): 4.829 s ± 0.518 s [User: 4.012 s, System: 0.208 s]
Range (min … max): 4.624 s … 6.294 s 10 runs
After
-----
Memory usage: 189MB
Benchmark 1: ./bin/lldb -n Slack -o quit
Time (mean ± σ): 4.182 s ± 0.025 s [User: 3.536 s, System: 0.192 s]
Range (min … max): 4.152 s … 4.233 s 10 runs
Differential revision: https://reviews.llvm.org/D118814
Have the different ::Parse.* methods return the demangled string
directly instead of having to go through ::GetBufferRef.
Differential revision: https://reviews.llvm.org/D118953
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.
Make sure that the shell tests use the same python interpreter as the
rest of the build instead of picking up `python` from the PATH.
It would be nice if we could use the _disallow helper, but that triggers
on invocations that specify python as the scripting language.
Rosetta crashlogs can have their own thread register state. Unlike the
other registers which ware directly listed under "threadState", the
Rosetta registers are nested under their own key in the JSON, as
illustrated below:
{
"threadState":
{
"rosetta":
{
"tmp2":
{
"value": 4935057216
},
"tmp1":
{
"value": 4365863188
},
"tmp0":
{
"value": 18446744073709551615
}
}
}
}
ClangUserExpression.h is relying on the forward declaration of
ClangExpressionParser in ClangFunctionCaller.h. This patch moves the
forward declaration to ClangUserExpression.h.
As raised here: https://lists.llvm.org/pipermail/llvm-dev/2021-November/153881.html
Now that VS2022 is on general release, LLVM is expected to build on VS2017, VS2019 and VS2022, which is proving hazardous to maintain due to changes in behaviour including preprocessor and constexpr changes. Plus of the few developers that work with VS, many have already moved to VS2019/22.
This patch proposes to raise the minimum supported version to VS2019 (16.x) - I've made the hard limit 16.0 or later, with the soft limit VS2019 16.7 - older versions of VS2019 are "allowed" (at your own risk) via the LLVM_FORCE_USE_OLD_TOOLCHAIN cmake flag.
Differential Revision: https://reviews.llvm.org/D114639
The existing instructions for lldb on Windows can be more explicit. This adds a few details on how to install various components and the easiest way to get to a working build.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D118425
Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve
the siginfo value from server.
Differential Revision: https://reviews.llvm.org/D118055
This means sve2 is enabled by default and the v8.8 mops (memcpy
and memset acceleration instructions) and HBC (hinted conditional
branch) extensions can be disassembled.
v9.3-a is equivalent to v8.8-a except that in v9.0-a sve2 was
enabled by default so v9.3-a includes that too.
MTE remains an optional extension, only enabled for specific CPUs.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D118358
We have been noticing issues with the lldb bots on builds using versions below clang 14 and dwarf 2, so to make sure we can get clean builds for a while, we are disabling the tests for those versions
Differential Revision: https://reviews.llvm.org/D118395
We have been noticing issues with the lldb bots on builds using versions below clang 14 and dwarf 2, so to make sure we can get clean builds for a while, we are disabling the tests for those versions
Differential Revision: https://reviews.llvm.org/D118395
There seems to be an issue on x86_64 when launching a ScriptdProcess.
This disables temporarely the test that causes the bot to timeout until
I finish investigating the issue.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This test is completely nondeterministic, environment-dependent and does
not test what it was supposed to test (reverting the associated patch
does not make it fail).
I tried to figure out what the patch was meant to fix to see if I can
create a better test with the current tools, but I was not able to
understand the problem (it sounds like it has something to do with local
classes, but I don't understand the details).
Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve
the siginfo value from server.
Differential Revision: https://reviews.llvm.org/D118055
Support synthesizing the siginfo_t type from the Platform plugin.
This type is going to be used by LLDB client to process the raw siginfo
data received from lldb-server without the necessity of relying
on target's debug info being present.
Differential Revision: https://reviews.llvm.org/D117707
In the rush to get the bot green, I did not realize I was building the
file with -gsplit-dwarf, and therefore the yaml ended up referring to a
file I did not check it.
This rebuilds the file without split dwarf.
Currently, running the test suite with LLVM_ENABLE_EXPENSIVE_CHECKS=On
causes a couple of tests to fail. This happens because they expect a
certain order of variables (all of them happen to use the "target
variable" command, but other lookup functions should suffer from the
same issues), all of which have the same name. Sort algorithms often
preserve the order of equivalent elements (in this case the entries in
the NameToDIE map), but that not guaranteed, and
LLVM_ENABLE_EXPENSIVE_CHECKS stresses that by pre-shuffling all inputs
before sorting.
While this could easily be fixed by relaxing the test expectations,
having a deterministic output seems like a worthwhile goal,
particularly, as this could have bigger consequences than just a
different print order -- in some cases we just pick the first entry that
we find, whatever that is. Therefore this patch makes the sort
deterministic by introducing another sort key -- UniqueCString::Sort
gets a value comparator functor, which can be used to sort elements with
the same name -- in the DWARF case we use DIERef::operator<, which
roughly equals the order in which the entries appear in the debug info,
and matches the current "accidental" order.
Using a extra functor seemed preferable to using stable_sort, as the
latter allocates extra O(n) of temporary memory.
I observed no difference in debug info parsing speed with this patch
applied.
Differential Revision: https://reviews.llvm.org/D118251
In D117744, llvm removed writing support for this format, breaking the
test. We may eventually want to remove reading support as well, but for
now I have converted the test to a yaml file to maintain coverage.
This patch introduces a new SBAPI method: `SBModule::IsFileBacked`
As the name suggests, it tells the user if the module's object file is
on disk or in memory.
rdar://68538278
Differential Revision: https://reviews.llvm.org/D118261
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Remove ConstString::StaticMemorySize as it is unused and superseded by
GetMemoryStats. It is referenced in a bunch of doc comments but I don't
really understand why. My best guess it that the comments were
copy-pasted from ConstString::MemorySize() even though it didn't make
sense there either. The implementation of StaticMemorySize was being
called on the MemoryPool, not on the ConstString itself.
Differential revision: https://reviews.llvm.org/D118091
This reverts commit ef82063207.
- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat
This adds an option --show-tags to "memory read".
(lldb) memory read mte_buf mte_buf+32 -f "x" -s8 --show-tags
0x900fffff7ff8000: 0x0000000000000000 0x0000000000000000 (tag: 0x0)
0x900fffff7ff8010: 0x0000000000000000 0x0000000000000000 (tag: 0x1)
Tags are printed on the end of each line, if that
line has any tags associated with it. Meaning that
untagged memory output is unchanged.
Tags are printed based on the granule(s) of memory that
a line covers. So you may have lines with 1 tag, with many
tags, no tags or partially tagged lines.
In the case of partially tagged lines, untagged granules
will show "<no tag>" so that the ordering is obvious.
For example, a line that covers 2 granules where the first
is not tagged:
(lldb) memory read mte_buf-16 mte_buf+16 -l32 -f"x" --show-tags
0x900fffff7ff7ff0: 0x00000000 <...> (tags: <no tag> 0x0)
Untagged lines will just not have the "(tags: ..." at all.
Though they may be part of a larger output that does have
some tagged lines.
To do this I've extended DumpDataExtractor to also print
memory tags where it has a valid execution context and
is asked to print them.
There are no special alignment requirements, simply
use "memory read" as usual. All alignment is handled
in DumpDataExtractor.
We use MakeTaggedRanges to find all the tagged memory
in the current dump, then read all that into a MemoryTagMap.
The tag map is populated once in DumpDataExtractor and re-used
for each subsequently printed line (or recursive call of
DumpDataExtractor, which some formats do).
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D107140
The tag map holds a sparse set of memory tags and allows
you to query ranges for tags.
Granules that do not have tags will be set to llvm::None.
to keep the ordering intact. If there are no tags for the
requested range we'll just return an empty result so that
callers don't need to check that all values are llvm::None.
This will be combined with MemoryTagManager's MakeTaggedRanges:
* MakeTaggedRanges
* Read from all those ranges
* Insert the results into the tag map
* Give the tag map to whatever needs to print tags
Which in this case will be "memory read"/DumpDataExtractor.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D112825
This is to be used when you want to know what subranges
of a larger range have memory tagging. Like MakeTaggedRange
but memory without tags is skipped and you get a list of ranges back.
Will be used later by DumpDataExtractor to show memory tags.
MakeTaggedRanges assumes that the memory regions it is
given are sorted in ascending order and do not overlap.
For the current use case where you get regions from
GetMemoryRegions and are on some Linux like OS, this is
reasonable to assume.
I've used asserts to check those conditions. In future
any API binding will check them up front to prevent a crash.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D112824
This patch makes use of c++ type checking and scoped enums to make
logging statements shorter and harder to misuse.
Defines like LIBLLDB_LOG_PROCESS are replaces with LLDBLog::Process.
Because it now carries type information we do not need to worry about
matching a specific enum value with the right getter function -- the
compiler will now do that for us.
The main entry point for the logging machinery becomes the GetLog
(template) function, which will obtain the correct Log object based on
the enum type. It achieves this through another template function
(LogChannelFor<T>), which must be specialized for each type, and should
return the appropriate channel object.
This patch also removes the ability to log a message if multiple
categories are enabled simultaneously as it was unused and confusing.
This patch does not actually remove any of the existing interfaces. The
defines and log retrieval functions are left around as wrappers around
the new interfaces. They will be removed in follow-up patch.
Differential Revision: https://reviews.llvm.org/D117490
I considered keeping this change strictly downstream. Since we still
have a bunch of places that check for Python 2, I figured it doesn't
harm to land it upstream and avoid the conflict when I eventually do
remove them (hopefully soon!).
Add statistics about the memory usage of the string pool. I'm
particularly interested in the memory used by the allocator, i.e. the
number of bytes actually used by the allocator it self as well as the
number of bytes allocated through the allocator.
Differential revision: https://reviews.llvm.org/D117914
This patch updates `dummy_scripted_process.py` to report the dummy
thread correctly to reflect the changes introduced by `d3e0f7e`.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch changes the `ScriptedInterface::ErrorWithMessage` method to
make it `static` which makes it easier to call.
The patch also updates its various call sites to reflect this change.
Differential Revision: https://reviews.llvm.org/D117374
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
When listing all the Scripted Threads of a ScriptedProcess, we can see that all
have the thread index set to 1. This is caused by the lldb_private::Thread
constructor, which sets the m_index_id member using the provided thread id `tid`.
Because the call to the super constructor is done before instantiating
the `ScriptedThreadInterface`, lldb can't fetch the thread id from the
script instance, so it uses `LLDB_INVALID_THREAD_ID` instead.
To mitigate this, this patch takes advantage of the `ScriptedThread::Create`
fallible constructor idiom to defer calling the `ScriptedThread` constructor
(and the `Thread` super constructor with it), until we can fetch a valid
thread id `tid` from the `ScriptedThreadInterface`.
rdar://87432065
Differential Revision: https://reviews.llvm.org/D117076
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds Exceptions to the list of supported stop reasons for
Scripted Threads.
The main motivation for this is that breakpoints are triggered as a
special exception class on ARM platforms, so adding it as a stop reason
allows the ScriptedProcess to selected the ScriptedThread that stopped at
a breakpoint (or crashed :p).
rdar://87430376
Differential Revision: https://reviews.llvm.org/D117074
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds support of multiple Scripted Threads in a ScriptedProcess.
This is done by fetching the Scripted Threads info dictionary at every
ScriptedProcess::DoUpdateThreadList and iterate over each element to
create a new ScriptedThread using the object instance, if it was not
already available.
This patch also adds the ability to pass a pointer of a script interpreter
object instance to initialize a ScriptedInterface instead of having to call
the script object initializer in the ScriptedInterface constructor.
This is used to instantiate the ScriptedThreadInterface from the
ScriptedThread constructor, to be able to perform call on that script
interpreter object instance.
Finally, the patch also updates the scripted process test to check for
multiple threads.
rdar://84507704
Differential Revision: https://reviews.llvm.org/D117071
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Since we can have multiple Scripted Threads per Scripted Process, having
only a single ScriptedThreadInterface (with a single object instance)
will cause the method calls to be done on the wrong object.
Instead, this patch creates a separate ScriptedThreadInterface for each
new lldb_private::ScriptedThread to make sure we interact with the right
instance.
rdar://87427911
Differential Revision: https://reviews.llvm.org/D117070
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds a new method to the Scripted Process interface to
retrive a dictionary of Scripted Threads. It uses the thread ID as a key
and the Scripted Thread instance as the value.
This dictionary will be used to create Scripted Threads in lldb and
perform calls to the python scripted thread object.
rdar://87427126
Differential Revision: https://reviews.llvm.org/D117068
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Only using that change in StringRef already decreases the number of
preoprocessed lines from 7837621 to 7776151 for LLVMSupport
Perhaps more interestingly, it shows that many files were relying on the
inclusion of StringRef.h to have the declaration from STLExtras.h. This
patch tries hard to patch relevant part of llvm-project impacted by this
hidden dependency removal.
Potential impact:
- "llvm/ADT/StringRef.h" no longer includes <memory>,
"llvm/ADT/Optional.h" nor "llvm/ADT/STLExtras.h"
Related Discourse thread:
https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831
This removes the non-address bits before we try to use
the addresses.
Meaning that when results are shown, those results won't
show non-address bits either. This follows what "memory read"
has done. On the grounds that non-address bits are a property
of a pointer, not the memory pointed to.
I've added testing and merged the find and read tests into one
file.
Note that there are no API side changes because "memory find"
does not have an equivalent API call.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D117299
Allow users to create aliases for aliases to raw input commands. That probably
sounds convoluted, so here's an example:
```
command alias some-setup env SOMEVAR=SOMEVALUE
```
This an alias based on `env`, which itself is an alias for `_regex-env`.
`_regex-env` is a `command regex` command, which takes raw input.
The above `some-setup` alias fails with:
```
error: Unable to create requested alias.
```
This change allows such aliases to be created. lldb already supports aliases to
aliases for parsed commands.
Differential Revision: https://reviews.llvm.org/D117259
The logic of `g_quiet` was inverted in D26243. This corrects the issue.
Without this, running `log timers enable` produces a high volume of incremental
timer output.
Differential Revision: https://reviews.llvm.org/D117837
The tryLockFor method from raw_fd_sotreamis the sole user of that
header, and it's not referenced in the mono repo. I still chose to keep
it (may be useful for downstream user) but added a transient type that's
forward declared to hold the duration parameter.
Notable changes:
- "llvm/Support/Duration.h" must be included in order to use tryLockFor.
- "llvm/Support/raw_ostream.h" no longer includes <chrono>
This sole change has an interesting impact on the number of processed
line, as measured by:
clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Support/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
before: 7917500
after: 7835142
Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831
The cleanup was manual, but assisted by "include-what-you-use". It consists in
1. Removing unused forward declaration. No impact expected.
2. Removing unused headers in .cpp files. No impact expected.
3. Removing unused headers in .h files. This removes implicit dependencies and
is generally considered a good thing, but this may break downstream builds.
I've updated llvm, clang, lld, lldb and mlir deps, and included a list of the
modification in the second part of the commit.
4. Replacing header inclusion by forward declaration. This has the same impact
as 3.
Notable changes:
- llvm/Support/TargetParser.h no longer includes llvm/Support/AArch64TargetParser.h nor llvm/Support/ARMTargetParser.h
- llvm/Support/TypeSize.h no longer includes llvm/Support/WithColor.h
- llvm/Support/YAMLTraits.h no longer includes llvm/Support/Regex.h
- llvm/ADT/SmallVector.h no longer includes llvm/Support/MemAlloc.h nor llvm/Support/ErrorHandling.h
You may need to add some of these headers in your compilation units, if needs be.
As an hint to the impact of the cleanup, running
clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Support/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
before: 8000919 lines
after: 7917500 lines
Reduced dependencies also helps incremental rebuilds and is more ccache
friendly, something not shown by the above metric :-)
Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831
Instrument the SB API with signposts on Darwin. This gives us a time
profile on whose behalf LLDB spends time (particularly when run via the
SBAPI from an IDE).
Differential revision: https://reviews.llvm.org/D117632
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
I revived lldb-instr to update the macros for D117712. I think the new
macros are simple enough that we add them by hand, but this tool can do
it automatically for you.
Differential revision: https://reviews.llvm.org/D117748
This patch works around what looks like a bug in Clang itself.
The error on the bot is:
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/40466/consoleText
In module 'LLVM_Utils' imported from /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/source/Plugins/ScriptInterpreter/Python/lldb-python.h:18:
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/Support/Error.h:720:3: error: 'llvm::Expected<bool>::(anonymous)' from module 'LLVM_Utils.Support.Error' is not present in definition of 'llvm::Expected<bool>' in module 'LLVM_Utils.Support.Error'
union {
^
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/Support/Error.h:720:3: note: declaration of '' does not match
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/llvm/include/llvm/Support/Error.h:720:3: note: declaration of '' does not match
1 error generated.
The intention is to revert this as soon as a proper fix has been identified!
rdar://87845391
This enables power-users to annotate lldb api functions with arbitrary
attributes. The motivation for this is being able to build liblldb as a
static library on windows (see discussion on D117564).
This should not be interpreted to mean that building liblldb is
supported in any way, but this does not cause any problems for us, and
can help users who really know what they are doing (or have no other
choice).
Its defaulting logic must go after `project(..)` to work correctly, but `project(..)` is often in a standalone condition making this
awkward, since the rest of the condition code may also need GNUInstallDirs.
The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward.
Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D117639
Although the memory tag commands use a memory tag manager to handle
addresses, that only removes the top byte.
That top byte is 4 bits of memory tag and 4 free bits, which is more
than it should strictly remove but that's how it is for now.
There are other non-address bit uses like pointer authentication.
To ensure the memory tag manager only has to deal with memory tags,
use the ABI plugin to remove the rest.
The tag access test has been updated to sign all the relevant pointers
and require that we're running on a system with pointer authentication
in addition to memory tagging.
The pointers will look like:
<4 bit user tag><4 bit memory tag><signature><bit virtual address>
Note that there is currently no API for reading memory tags. It will
also have to consider this when it arrives.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D117672
This better describes the intent of the method. Which for AArch64
is removing the top byte which includes the memory tags.
It does not include pointer signatures, for those we need to use
the ABI plugin. The rename makes this a little more clear.
It's a bit awkward that the memory tag manager is removing the whole
top byte not just the memory tags but it's an improvement for now.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D117671
We got a few crash reports that showed LLDB initializing Python on two
separate threads. Make sure Python is initialized exactly once.
rdar://87287005
Differential revision: https://reviews.llvm.org/D117601
std::chrono::duration types are not thread-safe, and they cannot be
concurrently updated from multiple threads. Currently, we were doing
such a thing (only) in the DWARF indexing code
(DWARFUnit::ExtractDIEsRWLocked), but I think it can easily happen that
someone else tries to update another statistic like this without
bothering to check for thread safety.
This patch changes the StatsDuration type from a simple typedef into a
class in its own right. The class stores the duration internally as
std::atomic<uint64_t> (so it can be updated atomically), but presents it
to its users as the usual chrono type (duration<float>).
Differential Revision: https://reviews.llvm.org/D117474
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
This macro was being used to select the proper import/export annotations
on SB classes. Non-windows clients do not have such requirements.
Instead introduce a new macro (LLDB_IN_LIBLLDB), which signals that
we're compiling liblldb itself (and should use dllexport). The default
(no macro) is to use dllimport. I've moved the macro definition to
SBDefines.h, since it only makes sense when building the API library.
Differential Revision: https://reviews.llvm.org/D117564
Use libobjc.A.dylib as a sentinel to detect situations where we're
reading libraries from process memory instead of the shared cache.
Differential revision: https://reviews.llvm.org/D117623
This was meant to be a replacement for the lldb-server sub-test suite of
the API tests, but it never got off the ground and it's making the
windows bot flaky.
Deleting it does not reduce test coverage as the original api test is
still around.
Return our PythonObject wrappers instead of raw PyObjects (obfuscated as
void *). This ensures that ownership (reference counts) of python
objects is automatically tracked.
Differential Revision: https://reviews.llvm.org/D117462
Provide minimal register definition defaults for working with servers
that implement neither target.xml nor qRegisterInfo packets. This is
useful e.g. when interacting with FreeBSD's kernel minimal gdbserver
that does not send target.xml but uses the same layout for its supported
register subset as GDB.
The prerequisite for this is the ability to determine the correct
architecture, e.g. from the target executable.
Differential Revision: https://reviews.llvm.org/D116896
The GIL must be held when calling any Python C API functions. In multithreaded applications that use callbacks this requirement can easily be violated by accident. A general tool to ensure GIL health is not available, but patching Python Py_INCREF to add an assert provides a basic health check:
```
+int PyGILState_Check(void); /* Include/internal/pystate.h */
+
#define Py_INCREF(op) ( \
+ assert(PyGILState_Check()), \
_Py_INC_REFTOTAL _Py_REF_DEBUG_COMMA \
((PyObject *)(op))->ob_refcnt++)
#define Py_DECREF(op) \
do { \
+ assert(PyGILState_Check()); \
PyObject *_py_decref_tmp = (PyObject *)(op); \
if (_Py_DEC_REFTOTAL _Py_REF_DEBUG_COMMA \
--(_py_decref_tmp)->ob_refcnt != 0) \
```
Adding this assertion causes around 50 test failures in LLDB. Adjusting the scope of things guarded by `py_lock` fixes them.
More background: https://docs.python.org/3/glossary.html#term-global-interpreter-lock
Patch by Ralf Grosse-Kunstleve
Differential Revision: https://reviews.llvm.org/D114722
Ensure that errors in `frame variable` are reflected in result object.
The statistics for `frame variable` show invocations as being successful, even
when executing one of the error paths.
This change replaces `result.GetErrorStream()` with `result.AppendError()`,
which also sets the status to `eReturnStatusFailed`.
Differential Revision: https://reviews.llvm.org/D116788
Recommitting after D116901 and D116863.
(cherry picked from commit 2c7d10c412)
This test for anonymous unions seems off. It tests the following:
```
union {
// fields
};
struct {
// fields
} var{...};
```
Both are anonymous types, but the first does not declare a variable and the
second one does. The test then checks that `frame var` can directly access the
fields of the anonymous union, but can't directly access the fields of the
anonymous struct variable.
The second test, to directly access the members of the struct variable, seems
pointless as similar code would not compile. A demonstration:
```
struct {
int a;
int z;
} a_z{23, 45};
printf("%d\n", a_z.a); // fine
printf("%d\n", a); // this does not compile
```
Since we can't directly access the fields in code, I'm not sure there's a
reason to test that lldb also can't directly access them (other than perhaps as
a regression test).
Differential Revision: https://reviews.llvm.org/D116863
This also removes the corresponding unit tests. I wrote them to sanity
check my original refactoring and checked them in because why not. The
current implementation, without the added complexity of indices, is
simple enough that we can do without it.
Currently, when connecting to a remote iOS device from the command line
on Apple Silicon, we end up using the host platform (PlatfromMacOSX)
instead of remote-ios (PlatformRemoteiOS). This happens because
PlatfromMacOSX includes arm64-apple-ios and arm64e-apple-ios as
compatible architectures, presumably to support debugging iOS Apps on
Apple Silicon [1].
This is a problem for debugging remote ios devices, because the host
platform doesn't look for an expanded shared cache on disk and as a
result we end up reading everything from memory, incurring a significant
performance hit.
The crux of this patch is to make PlatfromMacOSX *not* compatible with
arm64(e)-apple-ios. This also means that we now use remote-ios
(PlatformRemoteiOS) as the platform for debugging iOS apps on Apple
Silicon. This has the (unintended) side effect that unlike we do for the
host platform, we no longer check our local shared cache, and incur a
performance hit on debugging these apps.
To avoid that, PlatformRemoteiOS now also check the local cache to
support this use case, which is cheap enough to do unconditionally for
PlatformRemoteiOS.
[1] https://support.apple.com/guide/app-store/iphone-ipad-apps-mac-apple-silicon-fird2c7092da/mac
Differential revision: https://reviews.llvm.org/D117340
Update examples and docs to demonstrate using `__lldb_init_module` instead of
the idiom that checks for `lldb.debugger` at the top-level.
```
if __name__ == '__main__':
...
elif lldb.debugger:
...
```
Is replaced with:
```
if __name__ == '__main__':
...
def __lldb_init_module(debugger, internal_dict):
...
```
This change is for two reasons. First, it's generally encouraged not to only
use the convenience singletons (`lldb.{debugger,process,target,etc}`)
interactively from the `script` command. Second, there's a bug where
registering a python class as a command (using `command script add -c ...`),
result in the command not being runnable. Note that registering function-backed
commands does not have this bug.
Differential Revision: https://reviews.llvm.org/D117237
When LLDB receives a SIGINT while running the embedded Python REPL it
currently just crashes in ScriptInterpreterPythonImpl::Interrupt with an
error such as the one below:
Fatal Python error: PyThreadState_Get: the function must be called
with the GIL held, but the GIL is released (the current Python thread
state is NULL)
The faulty code that causes this error is this part of
ScriptInterpreterPythonImpl::Interrupt:
PyThreadState *state = PyThreadState_GET();
if (!state)
state = GetThreadState();
if (state) {
long tid = state->thread_id;
PyThreadState_Swap(state);
int num_threads = PyThreadState_SetAsyncExc(tid, PyExc_KeyboardInterrupt);
The obvious fix I tried is to just acquire the GIL before this code is
running which fixes the crash but the KeyboardInterrupt we want to raise
immediately is actually just queued and would only be raised once the
next line of input has been parsed (which e.g. won't interrupt Python
code that is currently waiting on a timer or IO from what I can see).
Also none of the functions we call here is marked as safe to be called
from a signal handler from what I can see, so we might still end up
crashing here with some bad timing.
Python 3.2 introduced PyErr_SetInterrupt to solve this and the function
takes care of all the details and avoids doing anything that isn't safe
to do inside a signal handler. The only thing we need to do is to
manually setup our own fake SIGINT handler that behaves the same way as
the standalone Python REPL signal handler (which raises a
KeyboardInterrupt).
From what I understand the old code used to work with Python 2 so I kept
the old code around until we officially drop support for Python 2.
There is a small gap here with Python 3.0->3.1 where we might still be
crashing, but those versions have reached their EOL more than a decade
ago so I think we don't need to bother about them.
Differential revision: https://reviews.llvm.org/D104886
Convert the `crashlog` command to be implemented as a class. The `Symbolicate`
function is switched to a class, to implement `get_long_help`. The text for the
long help comes from the help output generated by `OptionParser`. That is, the
output of `help crashlog` is the same as `crashlog --help`.
Differential Revision: https://reviews.llvm.org/D117165
This was left over from when I had used some pointer authentication
instructions to sign the pointer. Then I realised that simply setting
the top byte is enough to prove the ABI plugin is being called.
Top byte ignore is a feature of the armv8-a architecure and doesn't
need any extra compiler flags.
Implement the qXfer:siginfo:read that is used to read the siginfo_t
(extended signal information) for the current thread. This is currently
implemented on FreeBSD and Linux.
Differential Revision: https://reviews.llvm.org/D117113
Set the current thread ID to the thread where an event happened.
As a result, e.g. when a signal is delivered to a thread other than
the first one, the respective T packet refers to the signaled thread
rather than the first thread (with no stop reason). While this doesn't
strictly make a difference to the LLDB client, it is the expected
behavior.
Differential Revision: https://reviews.llvm.org/D117103
Due to a missing cast the << 60 always resulted in zero leaving
the top nibble empty. So we weren't actually testing that lldb
ignores those bits in addition to the tag bits.
Correct that and also set the top nibbles to ascending values
so that we can catch if lldb only removes one of the tag bits
and top nibble, but not both.
In future the tag manager will likely only remove the tag bits
and leave non-address bits to the ABI plugin but for now make
sure we're testing what we claim to implement.
"shell" is an alias to "platform shell -h --". Previously you would get this
help text:
(lldb) help shell
Run a shell command on the host. Expects 'raw' input (see 'help raw-input'.)
Syntax: shell <shell-command>
Command Options Usage:
'shell' is an abbreviation for 'platform shell -h --'
Since the code doesn't handle the base command having options
but the alias removing them. With these changes you get:
(lldb) help shell
Run a shell command on the host. Expects 'raw' input (see 'help raw-input'.)
Syntax: shell <shell-command>
'shell' is an abbreviation for 'platform shell -h --'
Note that we already handle a non-alias command having no options,
for example "quit":
(lldb) help quit
Quit the LLDB debugger.
Syntax: quit [exit-code]
Reviewed By: JDevlieghere, jingham
Differential Revision: https://reviews.llvm.org/D117004
This adds inline function support to NativePDB by parsing S_INLINESITE records
to retrieve inlinee line info and add them into line table at `ParseLineTable`.
Differential Revision: https://reviews.llvm.org/D116845
Several of the comments were annotating the wrong argument.
I caught this while reviewing this clean-up: 8afcfbfb8f
which was changing booleans to use true and false and in the this case the comment and the type looked mismatched.
Differential Revision: https://reviews.llvm.org/D116982
Addresses on AArch64 can have top byte tags, memory tags and pointer
authentication signatures in the upper bits.
While testing memory tagging I found that memory read couldn't
read a range if the two addresses had different tags. The same
could apply to signed pointers given the right circumstance.
(lldb) memory read mte_buf_alt_tag mte_buf+16
error: end address (0x900fffff7ff8010) must be greater than the start
address (0xa00fffff7ff8000).
Or it would try to read a lot more memory than expected.
(lldb) memory read mte_buf mte_buf_alt_tag+16
error: Normally, 'memory read' will not read over 1024 bytes of data.
error: Please use --force to override this restriction just once.
error: or set target.max-memory-read-size if you will often need a
larger limit.
Fix this by removing non address bits before we calculate the read
range. A test is added for AArch64 Linux that confirms this by using
the top byte ignore feature.
This means that if you do read with a tagged pointer the output
does not include those tags. This is potentially confusing but I think
overall it's better that we don't pretend that we're reading memory
from a range that the process is unable to map.
(lldb) p ptr1
(char *) $4 = 0x3400fffffffff140 "\x80\xf1\xff\xff\xff\xff"
(lldb) p ptr2
(char *) $5 = 0x5600fffffffff140 "\x80\xf1\xff\xff\xff\xff"
(lldb) memory read ptr1 ptr2+16
0xfffffffff140: 80 f1 ff ff ff ff 00 00 38 70 bc f7 ff ff 00 00 ........8p......
Reviewed By: omjavaid, danielkiss
Differential Revision: https://reviews.llvm.org/D103626
Previously we would persist the flags indicating whether the remote side
supports a particular feature across reconnects, which is obviously not
a good idea.
I implement the clearing by nuking (its the only way to be sure :) the
entire GDBRemoteCommunication object in the disconnect operation and
creating a new one upon connection. This allows us to maintain a nice
invariant that the GDBRemoteCommunication object (which is now a
pointer) exists only if it is connected. The downside to that is that a
lot of functions now needs to check the validity of the pointer instead
of blindly accessing the object.
The process communication does not suffer from the same issue because we
always destroy the entire Process object for a relaunch.
Differential Revision: https://reviews.llvm.org/D116539
If LLVM is configured without X86 as one of its TARGETS_TO_BUILD, then lldb
will crash when using X86 disassembler (which it does while running `image
show-unwind`).
While working on D116788 (properly error out of `frame var`), this libstdc++
specific `frame var` invocation was found in the tests. This test is in the
generic directory, but has this one case that requires libstdc++. The fix here
is to put the one `expect()` inside of a condition that checks for libstdc++.
Differential Revision: https://reviews.llvm.org/D116901
This test checks for `aarch64` but the lit config could also contain `arm64`.
This change adds `arm64` to make the test pass in all cases.
Differential Revision: https://reviews.llvm.org/D116912
Jim Ingham