The LEB128 type defined by the DWARF standard is explicitly a variable-length
encoding of an integer. LLDB had defined `uleb128` and `sleb128` types
to be 32-bit but in many places in both LLVM and LLDB we treat the maximum
width of LEB128 types to be 64, so let's remove these types and be
consistent.
Differential Revision: https://reviews.llvm.org/D150222
We had some custom classes that were used as the predicate for
`std::find_if`. It would be a lot simpler if we used lambdas instead.
Differential Revision: https://reviews.llvm.org/D150168
Modular just announced a new language called Mojo. This patch adds an entry in the language list in LLDB for minimal support (e.g. being able to create a TypeSystem for this language). We will later add debug info entries when the language matures.
Re-lands 04aa943be8ed5c03092e2a90112ac638360ec253 with modifications
to fix tests.
I originally reverted this because it caused a test to fail on Linux.
The problem was that I inverted a condition on accident.
Use templates to simplify {Get,Set}PropertyAtIndex. It has always
bothered me how cumbersome those calls are when adding new properties.
After this patch, SetPropertyAtIndex infers the type from its arguments
and GetPropertyAtIndex required a single template argument for the
return value. As an added benefit, this enables us to remove a bunch of
wrappers from UserSettingsController and OptionValueProperties.
Differential revision: https://reviews.llvm.org/D149774
There are many situations where we'll iterate over a SymbolContextList
with the pattern:
```
SymbolContextList sc_list;
// Fill in sc_list here
for (auto i = 0; i < sc_list.GetSize(); i++) {
SymbolContext sc;
sc_list.GetSymbolAtContext(i, sc);
// Do work with sc
}
```
Adding an iterator to iterate over the instances directly means we don't
have to do bounds checking or create a copy of every element of the
SymbolContextList.
Differential Revision: https://reviews.llvm.org/D149900
REPL implementations don't have an easy way to know that an expression has been evaluated, so I'm adding a simple function for that. In the future we can add another hook for meta commands.
Differential Revision: https://reviews.llvm.org/D149719
`StartEventHandlerThread` and `StopEventHandlerThread` are available to the SwiftREPL even though they are protected because SwiftREPL is a friend class of Debugger. I'm developing my own REPL and having access to these functions, including `FlushProcessOutput`, is desirable.
Differential Revision: https://reviews.llvm.org/D149717
In code we use `#include "llvm/Lib/Header.h"` which is located in
"llvm/include/llvm/Lib/Header.h", so we use "llvm/include/" as a header
search path. We should put modulemaps in the same directory and
shouldn't rely on clang to search in immediate subdirectories.
rdar://106677321
Differential Revision: https://reviews.llvm.org/D148776
The qHostInfo packet in the gdb-remote communication protocol specifies
that distribution_id can be set, so lldb handles that. But we store that
in the ArchSpec representing the "Host" platform (whatever platform the
debug server is running on). This field is otherwise unused in ArchSpec,
so it would be a lot easier if we stored that information at the
gdb-remote communication layer.
Sidenote: The distribution_id field is currently unused but I did not
want to remove it in case some folks found it useful (e.g. in downstream
forks).
Differential Revision: https://reviews.llvm.org/D149697
As far as I can tell, this just computes the filename of the FileSpec,
which is already conveniently stored in m_filename. We can use
FileSpec::GetFilename() instead.
Differential Revision: https://reviews.llvm.org/D149663
Expression evaluation allocates memory for storing intermediate data during evaluation. For it to work properly it has to be allocated within target's available address space, for example within first 0xFFFF bytes for the 16-bit MSP430. The memory for such targets can be very tightly packed, but not all targets support GetMemoryRegionInfo API to pick an unused region, like MSP430 with MSPDebug GDB server.
These settings allow the programmer to manually pick precisely where and how much memory to allocate for expression evaluation in order not to overlap with existing data in process memory.
Reviewed By: bulbazord
Differential Revision: https://reviews.llvm.org/D149262
The majority of call sites are nullptr as the execution context.
Refactor OptionValueProperties to make the argument optional and
simplify all the callers.
Various OptionValue related classes are passing around will_modify but
the value is never used. This patch simplifies the interfaces by
removing the redundant argument.
Similar to fdbe7c7faa54, refactor OptionValueProperties to return a
std::optional instead of taking a fail value. This allows the caller to
handle situations where there's no value, instead of being unable to
distinguish between the absence of a value and the value happening the
match the fail value. When a fail value is required,
std::optional::value_or() provides the same functionality.
Refactor OptionValue to return a std::optional instead of taking a fail
value. This allows the caller to handle situations where there's no
value, instead of being unable to distinguish between the absence of a
value and the value happening the match the fail value. When a fail
value is required, std::optional::value_or() provides the same
functionality.
llvm has a structure for maps where the key's type is a string. Using
that also means that the keys for OptionValueDictionary don't stick
around forever in ConstString's StringPool (even after they are gone).
The only thing we lose here is ordering: iterating over the map where the keys
are ConstStrings guarantees that we iterate in alphabetical order.
StringMap makes no guarantees about the ordering when you iterate over
the entire map.
Differential Revision: https://reviews.llvm.org/D149482
Add a new setting (debugger.external-editor) to specify an external
editor. The setting takes precedence over the existing
LLDB_EXTERNAL_EDITOR environment variable.
Differential revision: https://reviews.llvm.org/D149565
The unique_ptr prettyprinter calls `GetValueOfLibCXXCompressedPair`,
which looks for a `__value_` child. However, when the second value in
the compressed pair is not an empty class, there are two `__value_`
children because `__compressed_pair` derives twice from
`__compressed_pair_elem`, one for each member of the pair. And then the
lookup fails because it's ambiguous.
This patch makes the following changes:
- Rename `GetValueOfLibCXXCompressedPair` to
`GetFirstValueOfLibCXXCompressedPair`, and add a similar function to
get the second value. Put both functions in
Plugin/Language/CPlusPlus/LibCxx.cpp because it seems inappropriate to
have libcxx-specific helpers separate from all the libcxx-dependent
code.
- Read the second value of the `__ptr_` pair and display a "deleter"
child in the unique_ptr synthetic child provider, when available.
- Add a test case for the non-empty deleter case.
Differential Revision: https://reviews.llvm.org/D148662
This patch refactors the macOS implementation of
OpenFileInExternalEditor. It fixes an AppleEvent memory leak, the
caching of LLDB_EXTERNAL_EDITOR and speculatively fixes a crash when
CFURL is NULL (rdar://108633464). The new code also improves error
handling, readability and documents calls to the CoreFoundation Launch
Services APIs.
A bunch of the Launch Services APIs have been deprecated
(LSFindApplicationForInfo, LSOpenURLsWithRole). The preferred API is
LSOpenCFURLRef but it doesn't specifying the "location" Apple Event
which is used to highlight the current line and switching over would
regress the existing behavior.
rdar://108633464
Differential revision: https://reviews.llvm.org/D149482
This generalises the GetXcodeSDKPath hook to a GetSDKRoot path which
will be re-used for the Windows support to compute a language specific
SDK path on the platform. Because there may be other options that we
wish to use to compute the SDK path, sink the XcodeSDK parameter into
a structure which can pass a disaggregated set of options. Furthermore,
optionalise the parameter as Xcode is not available for all platforms.
Differential Revision: https://reviews.llvm.org/D149397
Reviewed By: JDevlieghere
Some LLDB set ups need to hide certain commands for security reasons, so I'm adding a flag that allows removing non-user commands.
Differential Revision: https://reviews.llvm.org/D149312
These don't really need to be in ConstStrings. It's nice that comparing
ConstStrings is fast (just a pointer comparison) but the cost of
creating the ConstString usually already includes the cost of doing a
StringRef comparison anyway, so this is just extra work and extra memory
consumption for basically no benefit.
Differential Revision: https://reviews.llvm.org/D149300
This is useful in contexts where you have multiple languages in play:
You may be stopped in a frame for language A, but want to set a watchpoint
with an expression using language B. The current way to do this is to
use the setting `target.language` while setting the watchpoint and
unset it after the watchpoint is set, but that's kind of clunky and
somewhat error-prone. This should add a better way to do this.
rdar://108202559
Differential Revision: https://reviews.llvm.org/D149111
This patch improves breakpoint management when doing interactive
scripted process debugging.
In other to know which process set a breakpoint, we need to do some book
keeping on the multiplexer scripted process. When initializing the
multiplexer, we will first copy breakpoints that are already set on the
driving target.
Everytime we launch or resume, we should copy breakpoints from the
multiplexer to the driving process.
When creating a breakpoint from a child process, it needs to be set both
on the multiplexer and on the driving process. We also tag the created
breakpoint with the name and pid of the originator process.
This patch also implements all the requirement to achieve proper
breakpoint management. That involves:
- Adding python interator for breakpoints and watchpoints in SBTarget
- Add a new `ScriptedProcess.create_breakpoint` python method
Differential Revision: https://reviews.llvm.org/D148548
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds a new convience constructor to the SBError to initialize
it with a string message to avoid having to create the object and call
the `SetErrorString` method afterwards.
This is very handy to report errors from lldb scripted affordances.
Differential Revision: https://reviews.llvm.org/D148401
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch augments lldb's event listeners with a new shadow mode.
As the name suggests, this mode allows events to be copied to an
additional listener to perform event monitoring, without interferring
with the event life cycle.
One of our use case for this, is to be able to listen to public process
events while making sure the events will still be delivered to the
default process listener (the debugger listener in most cases).
Differential Revision: https://reviews.llvm.org/D148397
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch is a simple refactor that unifies the default and hijack
listener methods and attributes between ProcessAttachInfo and
ProcessLaunchInfo.
These 2 classes are both derived from the ProcessInfo base class so this
patch moves the listeners attributes and getter/setter methods to the
base class.
Differential Revision: https://reviews.llvm.org/D148395
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
While debugging a Scripted Process, in order to update its state and
work nicely with lldb's execution model, it needs to toggle its private
state from running to stopped, which will result in broadcasting a
process state changed event to the debugger listener.
Originally, this state update was done systematically in the Scripted
Process C++ plugin, however in order to make scripted process
interactive, we need to be able to update their state dynamically.
This patch makes use of the recent addition of the
SBProcess::ForceScriptedState to programatically, and moves the
process private state update to the python implementation of the resume
method instead of doing it in ScriptedProcess::DoResume.
This patch also removes the unused ShouldStop & Stop scripted
process APIs, and adds new ScriptedInterface transform methods for
boolean arguments. This allow the user to programmatically decide if
after running the process, we should stop it (which is the default setting).
Differential Revision: https://reviews.llvm.org/D145295
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch introduces a new method to the SBProcess API called
ForceScriptedState. As the name suggests, this affordance will allow the
user to alter the state of the scripted process programatically.
This is necessary to update the scripted process state when perform
interactive debugging.
Differential Revision: https://reviews.llvm.org/D145294
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This is a user facing action, it is meant to focus the user's attention on
something other than the 0th frame when you stop somewhere where that's
helpful. For instance, stopping in pthread_kill after an assert will select
the assert frame.
This is not something you want to have happen internally in lldb, both
because internally you really don't want the selected frame changing out
from under you, and because the recognizers can do arbitrary work, and that
can cause deadlocks or other unexpected behavior.
However, it's not something that the current code does
explicitly after a stop has been delivered, it's expected to happen implicitly
as part of stopping. I changing this to call SMRF explicitly after a user
stop, but that got pretty ugly quickly.
So I added a bool to control whether to run this and audited all the current
uses to determine whether we're returning to the user or not.
Differential Revision: https://reviews.llvm.org/D148863
We have a handful of places in LLDB where we try to outsmart the logic
in Mangled to determine whether a string is mangled or not. There's at
least one place (*) where we are getting this wrong and causes a subtle
bug. The `cstring_is_mangled` is cheap enough that we should always rely
on it to determine whether a string is mangled or not.
(*) `ObjectFileMachO` assumes that a symbol that starts with a double
underscore (such as `__pthread_kill`) is mangled. That's mostly
harmless, until you use `function.name-without-args` in the frame
format. The formatter calls `Symbol::GetNameNoArguments()` which is a
wrapper around `Mangled::GetName(ePreferDemangledWithoutArguments)`. The
latter will first try using the appropriate language plugin to get the
demangled name without arguments, and if that fails, falls back to
returning the demangled name. Because we forced Mangled to treat the
symbol as a mangled name (even though it's not) there's no demangled
name. The result is that frames don't show any symbol at all.
Differential revision: https://reviews.llvm.org/D148846
I received a crash report in DiagnosticManager that was caused by a
nullptr diagnostic having been added. The API allows passing in a null
unique_ptr, but all the methods are written assuming that all pointers
a dereferencable. This patch makes it impossible to add a null
diagnostic.
rdar://107633615
Differential Revision: https://reviews.llvm.org/D148823
This patch should address an issue that caused the process public run
lock to not be updated during a process launch/attach when the process
stops.
That caused the public run lock to report its state as running while the
process state is stopped. This prevents the users to interact with the
process (through the command line or via the SBAPI) since it's
considered still running.
To address that, this patch refactors the name of the internal hijack
listeners to a specific pattern `lldb.internal.<action>.hijack` that
are used to ensure that we've attached to or launched a process successfully.
Then, when updating the process public state, after updating the state
value, if the process is not hijacked externally, meaning if the process
doens't have a hijack listener that matches the internal hijack
listeners pattern, we can update the public run lock accordingly.
rdar://108283017
Differential Revision: https://reviews.llvm.org/D148400
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
These probably do not need to be in the ConstString StringPool as they
don't really need any of the advantages that ConstStrings offer.
Lifetime for these things is always static and we never need to perform
comparisons for setting descriptions.
Differential Revision: https://reviews.llvm.org/D148679
