These functions have been NO-OPs since 2014 (44d937820b). Remove them
and deprecate the corresponding functions in SBDebugger.
Differential revision: https://reviews.llvm.org/D158000
As stated on Discourse*, these methods have been deprecated. I am
removing their implementation. They will now do nothing and return a
value indicating failure (where appropriate).
Due to the LLDB project's commitment to ABI stability at the SB API
layer, we cannot remove these symbols completely.
Discourse link: https://discourse.llvm.org/t/do-you-use-the-threading-functionality-in-sbhostos/71973
Make SBTarget::AddModule possibly call out to an external program to
find the binary by UUID if it can't be found more easily, the same
way `target modules add -u ...` works from the commandline.
If the Target does not have an architecture set yet, use the
Module's Arch to initialize it. Allows an API writer to create
a target with no arch, and inherit it from the first binary they
load with AddModules.
Differential Revision: https://reviews.llvm.org/D157659
rdar://113657555
StreamFile subclasses Stream (from lldbUtility) and is backed by a File
(from lldbHost). It does not depend on anything from lldbCore or any of its
sibling libraries, so I think it makes sense for this to live in
lldbHost instead.
Differential Revision: https://reviews.llvm.org/D157460
In a809720102 I refactored some logic to
deal with the clang resource directory in standalone LLDB builds.
However, this logic escaped me because it only runs when you do not
build LLDB.framework.
Differential Revision: https://reviews.llvm.org/D156763
This patch adds the ability to pass native types from the script
interpreter to methods that use a {SB,}StructuredData argument.
To do so, this patch changes the `ScriptedObject` struture that holds
the pointer to the script object as well as the originating script
interpreter language. It also exposes that to the SB API via a new class
called `SBScriptObject`.
This structure allows the debugger to parse the script object and
convert it to a StructuredData object. If the type is not compatible
with the StructuredData types, we will store its pointer in a
`StructuredData::Generic` object.
This patch also adds some SWIG typemaps that checks the input argument to
ensure it's either an SBStructuredData object, in which case it just
passes it throught, or a python object that is NOT another SB type, to
provide some guardrails for the user.
rdar://111467140
Differential Revision: https://reviews.llvm.org/D155161
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
`Instruction::TestEmulation` takes a `Stream *` and checks it for validity.
However, this is unnecessary as we can always ensure that we never pass
`nullptr` for the `Stream` argument. The only use of
`Instruction::TestEmulation` currently is `SBInstruction::TestEmulation`
which gets the `Stream` from an `SBStream`, and `SBStream::ref` can
return a `Stream &` guaranteed.
Differential Revision: https://reviews.llvm.org/D154757
Also, make it possible for new Targets which haven't been added to
the TargetList yet to check for interruption, and add a few more
places in building modules where we can check for interruption.
Differential Revision: https://reviews.llvm.org/D154542
Fix incorrect uses of formatv specifiers in LLDB_LOG. Unlike Python,
arguments must be numbered. All the affected log statements take
llvm:Errors so use the LLDB_LOG_ERROR macro instead.
Differential revision: https://reviews.llvm.org/D154532
None of these need to be in the ConstString StringPool. For the most
part they are constant strings and do not require fast comparisons.
I did change IOHandlerDelegateMultiline slightly -- specifically, the
`m_end_line` member always has a `\n` at the end of it now. This was so
that `IOHandlerGetControlSequence` can always return a StringRef. This
did require a slight change to `IOHandlerIsInputComplete` where we must
drop the newline before comparing it against the input parameter.
Differential Revision: https://reviews.llvm.org/D151597
If you pass `nullptr` (or `None` from python) to SBPlatform::SetSDKRoot,
LLDB crashes. Let's be more resilient to `nullptr` here.
Differential Revision: https://reviews.llvm.org/D152962
These don't need to be ConstStrings. They don't really benefit much from
deduplication and comparing them isn't on a hot path, so they don't
really benefit much from quick comparisons.
Differential Revision: https://reviews.llvm.org/D152331
When hitting an lldbassert in a non-assert build, we emit a blurb
including the assertion, the triggering file and line and a pretty
backtrace leading up to the issue. Currently, this is all printed to
stderr. That's fine on the command line, but when used as library, for
example from Xcode, this information doesn't make it to the user. This
patch uses the diagnostic infrastructure to report LLDB asserts as
diagnostic events.
The patch is slightly more complicated than I would've liked because of
layering. lldbassert is part of Utility while the debugger diagnostics
are implemented in Core.
Differential revision: https://reviews.llvm.org/D152866
Existing callers of `GetChildAtIndex` pass true for can_create. This change
makes true the default value, callers don't have to pass an opaque true.
See also D151966 for the same change to `GetChildMemberWithName`.
Differential Revision: https://reviews.llvm.org/D152031
This patch improves the way the user can save the process state into a
corefile by adding completion handler that would provide tab completion
for the corefile path and also resolves the corefile path to expand
relative path.
Differential Revision: https://reviews.llvm.org/D152842
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
It turns out all existing callers of `GetChildMemberWithName` pass true for `can_create`.
This change makes `true` the default value, callers don't have to pass an opaque true.
Differential Revision: https://reviews.llvm.org/D151966
Broadcasters don't need their names in the StringPool. It doesn't
benefit from fast comparisons and doesn't benefit from uniqueness.
Differential Revision: https://reviews.llvm.org/D152220
This patch add the ability for the user to set a label for a target.
This can be very useful when debugging targets with the same executables
in the same session.
Labels can be set either at the target creation in the command
interpreter or at any time using the SBAPI.
Target labels show up in the `target list` output, following the target
index, and they also allow the user to switch targets using them.
rdar://105016191
Differential Revision: https://reviews.llvm.org/D151859
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
As with D151615, which changed `GetIndexOfChildMemberWithName` to take a `StringRef`
instead of a `ConstString`, this change does the same for `GetIndexOfChildWithName`.
Differential Revision: https://reviews.llvm.org/D151811
There were two bugs here.
eMatchTypeStartsWith searched for "symbol_name" by adding ".*" to the
end of the symbol name and treating that as a regex, which isn't
actually a regex for "starts with". The ".*" is in fact a no-op. When
we finally get to comparing the name, we compare against whatever form
of the name was in the accelerator table. But for C++ that might be
the mangled name. We should also try demangled names here, since most
users are going the see demangled not mangled names. I fixed these
two bugs and added a bunch of tests for FindGlobalVariables.
This change is in the DWARF parser code, so there may be a similar bug
in PDB, but the test for this was already skipped for Windows, so I
don't know about this.
You might theoretically need to do this Mangled comparison in
DWARFMappedHash::MemoryTable::FindByName
except when we have names we always chop them before looking them up
so I couldn't see any code paths that fail without that change. So I
didn't add that to this patch.
Differential Revision: https://reviews.llvm.org/D151940
`GetChildMemberWithName` does not need a `ConstString`. This change makes the function
take a `StringRef` instead, which alleviates the need for callers to construct a
`ConstString`. I don't expect this change to improve performance, only ergonomics.
This is in support of Alex's effort to replace `ConstString` where appropriate.
There are related `ValueObject` functions that can also be changed, if this is accepted.
Differential Revision: https://reviews.llvm.org/D151615
This was just a thinko. The API StackFrame::GetVariableList takes a
bool for "get_file_globals" which if true will also find file statics
and file globals. But we only were passing that as true if the
ValueType was eValueTypeVariableGlobal, which meant that we never find
file statics. It's okay if we cast too wide a net when we do
GetVariableList as later on we check against the ValueType to filter
globals from statics.
There was a test that had a whole bunch of globals and tested
FindValue on all of them, but had no statics. So I just made one of
the globals a file static, which verifies the fix.
Differential Revision: https://reviews.llvm.org/D151392
This doesn't need to be in the ConstString StringPool. There's little
benefit to having these be unique, and we don't need fast comparisons on
them.
Differential Revision: https://reviews.llvm.org/D151524
This patch refactors the `StructuredData::Integer` class to make it
templated, makes it private and adds 2 public specialization for both
`int64_t` & `uint64_t` with a public type aliases, respectively
`SignedInteger` & `UnsignedInteger`.
It adds new getter for signed and unsigned interger values to the
`StructuredData::Object` base class and changes the implementation of
`StructuredData::Array::GetItemAtIndexAsInteger` and
`StructuredData::Dictionary::GetValueForKeyAsInteger` to support signed
and unsigned integers.
This patch also adds 2 new `Get{Signed,Unsigned}IntegerValue` to the
`SBStructuredData` class and marks `GetIntegerValue` as deprecated.
Finally, this patch audits all the caller of `StructuredData::Integer`
or `StructuredData::GetIntegerValue` to use the proper type as well the
various tests that uses `SBStructuredData.GetIntegerValue`.
rdar://105575764
Differential Revision: https://reviews.llvm.org/D150485
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
LLDB should guarantee that the strings returned by SBAPI methods
live forever. I went through every method that returns a string and made
sure that it was added to the ConstString StringPool before returning if
it wasn't obvious that it was already doing so.
I've also updated the docs to document this behavior.
Differential Revision: https://reviews.llvm.org/D150804
This reverts commit 2bea2d7b07.
It introduced following failures on buildbot lldb-aarch64-windows:
lldb-api :: functionalities/process_save_core/TestProcessSaveCore.py
lldb-api :: python_api/symbol-context/TestSymbolContext.py
Differential Revision: https://reviews.llvm.org/D149625
Many SB classes have public constructors or methods involving types that
are private. Some are more obvious (e.g. containing lldb_private in the
name) than others (lldb::FooSP is usually std::shared_pointer<lldb_private::Foo>).
This commit explicitly does not address FileSP, so I'm leaving that one
alone for now.
Some of these were for other SB classes to use and should have been made
protected/private with a friend class entry added. Some of these were
public for some of the swig python helpers to use. I put all of those
functions into a class and made them static methods. The relevant SB
classes mark that class as a friend so they can access those
private/protected members.
I've also removed an outdated SBStructuredData test (can you guess which
constructor it was using?) and updated the other relevant tests.
Differential Revision: https://reviews.llvm.org/D150157
Re-lands 04aa943be8 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.
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
This is an optional request, but supporting it makes the experience
better when re-launching a big binary that takes significant time to
parse: instead of tearing down and re-create the whole session we just
need to kill the current process and launch a new one.
Some non-obvious comments that might help review this change:
* After killing the process, we get an "exited" event for it. Because
the process no longer exists some interesting things can occur that
manifest as flaky failures if not dealt with:
- `EventIsProcessEvent` relies on `SBEvent::GetBroadcasterClass`,
which can crash if the broadcaster is no longer there: the event
only holds a weak_ptr to its broadcaster, and `GetBroadcasterClass`
uses it without checking.
Other `EventIs*` functions look at the flavor of the EventData, so I
have modified EventIsProcessEvent to do that.
- We keep the PID of the old process so we can detect its "exited"
event and not terminate the whole session. But sometimes the
SBProcess we get from the event won't have a PID, for some reason.
* I have factored out the code to launch a process out to a new
LaunchProcess function, so it can be used from both `request_launch`
and `request_restart`.
* The restart_runInTerminal test has the same problem with debug builds
as the original runInTerminal test: when attaching to the launcher
instance of lldb-vscode it takes a long time to parse its debug info.
I have used the same workaround to disable that particular test for
debug builds.
Differential Revision: https://reviews.llvm.org/D147831
There's no reason to create an entire new filespec to mutate and grab
data from when we can just grab the data directly.
Differential Revision: https://reviews.llvm.org/D149625
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.
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 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
Instead of taking a `const std::string &` we can take an
`llvm::StringRef`. The motivation for this change is that many of the
callers of `ParseJSON` end up creating a temporary `std::string` from an existing
`StringRef` or `const char *` in order to satisfy the API. There's no
reason we need to do this.
Differential Revision: https://reviews.llvm.org/D148579
There's no reason these strings need to be in the ConstString
StringPool, they're already string literals with static lifetime.
I plan on addressing other similar functions in follow up commits.
Differential Revision: https://reviews.llvm.org/D147833
Currently, SBTarget::SetModuleLoadAddress does not accept large slides
needed to load images in high memory. This function should always have
taken an unsigned as the slide, as it immediately passes it to
Target::SetSectionLoadAddress which takes an unsigned.
This patch adds an overload and exposes that to SWIG instead of the
signed variant. I've marked the signed variant as deprecated and added
check that the slide is positive.
rdar://101355155
Differential revision: https://reviews.llvm.org/D147482
Adding a new SBDebugger::SetDestroyCallback() API.
This API can be used by any client to query for statistics/metrics before
exiting debug sessions.
Differential Revision: https://reviews.llvm.org/D143520
