TargetList::CreateTarget automatically adds created target to the list, however,
CommandObjectTargetCreate does some additional preparation after creating a target
and which can fail. The command should remove created target if it failed. Since
the function has many ways to return, scope guard does this work safely.
Changes to the TargetList make target adding and selection more transparent.
Other changes remove unnecessary SetSelectedTarget after CreateTarget.
Differential Revision: https://reviews.llvm.org/D93052
Add a 'can_connect' parameter to Process plugin initialization, and use
it to filter plugins to these capable of remote connections. This is
used to prevent 'process connect' from picking up a plugin that can only
be used locally, e.g. the legacy FreeBSD plugin.
Differential Revision: https://reviews.llvm.org/D91810
Instead of having a custom error message, propagate the llvm::Error from
SystemInitializerCommon. I didn't realize we had this overload until
Pavel mentioned it in D90987 today.
During active replay, the ::Initialize call is replayed like any other
SB API call and the return value is ignored. Since we can't intercept
this, we terminate here before the uninitialized debugger inevitably
crashes.
Differential revision: https://reviews.llvm.org/D90987
SBType::GetArrayElementType should return the actual type, not the
canonical type (e.g. int32_t, not the underlying int).
Added a test case to validate the new behavior. I also ran all other
tests on Linux (ninja check-lldb), they all pass.
Differential revision: https://reviews.llvm.org/D90318
For performance reasons the reproducers don't copy the files captured by
the file collector eagerly, but wait until the reproducer needs to be
generated.
This is a problematic when LLDB crashes and we have to do all this
signal-unsafe work in the signal handler. This patch uses a similar
trick to clang, which has the driver invoke a new cc1 instance to do all
this work out-of-process.
This patch moves the writing of the mapping file as well as copying over
the reproducers into a separate process spawned when lldb crashes.
Differential revision: https://reviews.llvm.org/D89600
Renamed ThreadIntelPT to TreaceThread, making it a top-level class. I noticed that this class can and shuld work for any trace plugin and there's nothing intel-pt specific in it.
With that TraceThread change, I was able to move most of the json file parsing logic to the base class TraceSessionFileParser, which makes adding new plug-ins easier.
This originally was part of https://reviews.llvm.org/D89283
Differential Revision: https://reviews.llvm.org/D89408
When doing a standalone build (i.e., building just LLDB against an existing
LLVM/Clang installation), LLDB is currently unable to find any Clang resource
directory that contains all the builtin headers we need to parse real source
code. This causes several tests that actually parse source code on disk within
the expression parser to fail (most notably nearly all the import-std-module
tests).
The reason why LLDB can't find the resource directory is that we search based on
the path of the LLDB shared library path. We assumed that the Clang resource
directory is in the same prefix and has the same relative path to the LLDB
shared library (e.g., `../clang/10.0.0/include`). However for a standalone build
where the existing Clang can be anywhere on the disk, so we can't just rely on
the hardcoded relative paths to the LLDB shared library.
It seems we can either solve this by copying the resource directory to the LLDB
installation, symlinking it there or we pass the path to the Clang installation
to the code that is trying to find the resource directory. When building the
LLDB framework we currently copy the resource directory over to the framework
folder (this is why the import-std-module are not failing on the Green Dragon
standalone bot).
This patch symlinks the resource directory of Clang into the LLDB build
directory. The reason for that is simply that this is only needed when running
LLDB from the build directory. Once LLDB and Clang/LLVM are installed the
already existing logic can find the Clang resource directory by searching
relative to the LLDB shared library.
Reviewed By: kastiglione, JDevlieghere
Differential Revision: https://reviews.llvm.org/D88581
Every call to the protected SBAddress constructor and the SetAddress
method takes the address of a valid object which means we might as well
pass it as a const reference instead of a pointer and drop the null
check.
Differential revision: https://reviews.llvm.org/D88249
In MinGW world, UNIX like lib prefix is preferred for the libraries.
This patch adjusts CMake files to do that.
Differential Revision: https://reviews.llvm.org/D87517
This patch adds a way to fetch breakpoint metadatas as a serialized
`Structured` Data format (JSON). This can be used by IDEs to update
their UI when a breakpoint is set or modified from the console.
rdar://11013798
Differential Revision: https://reviews.llvm.org/D87491
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Add a reproducer verifier that catches:
- Missing or invalid home directory
- Missing or invalid working directory
- Missing or invalid module/symbol paths
- Missing files from the VFS
The verifier is enabled by default during replay, but can be skipped by
passing --reproducer-no-verify.
Differential revision: https://reviews.llvm.org/D86497
This patch adds the ability to use a custom interpreter with the
`platform shell` command. If the user set the `-s|--shell` option
with the path to a binary, lldb passes it down to the platform's
`RunShellProcess` method and set it as the shell to use in
`ProcessLaunchInfo to run commands.
Note that not all the Platforms support running shell commands with
custom interpreters (i.e. RemoteGDBServer is only expected to use the
default shell).
This patch also makes some refactoring and cleanups, like swapping
CString for StringRef when possible and updating `SBPlatformShellCommand`
with new methods and a new constructor.
rdar://67759256
Differential Revision: https://reviews.llvm.org/D86667
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Add a reproducer verifier that catches:
- Missing or invalid home directory
- Missing or invalid working directory
- Missing or invalid module/symbol paths
- Missing files from the VFS
The verifier is enabled by default during replay, but can be skipped by
passing --reproducer-no-verify.
Differential revision: https://reviews.llvm.org/D86497
Extract all the provider related logic from Reproducer.h and move it
into its own header ReproducerProvider.h. These classes are seeing most
of the development these days and this reorganization reduces
incremental compilation from ~520 to ~110 files when making changes to
the new header.
Provider a wrapper around llvm::sys::path::home_directory in the
FileSystem class. This will make it possible for the reproducers to
intercept the call in a central place.
This patch adds the infrastructure to have language specific REPL init
files. It's the foundation work to a following patch that will introduce
Swift REPL init file.
When lldb is launched with the `--repl` option, it will look for a REPL
init file in the home directory and source it. This overrides the
default `~/.lldbinit`, which content might make the REPL behave
unexpectedly. If the REPL init file doesn't exists, lldb will fall back
to the default init file.
rdar://65836048
Differential Revision: https://reviews.llvm.org/D86242
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch is a big sed to rename the following variables:
s/PYTHON_LIBRARIES/Python3_LIBRARIES/g
s/PYTHON_INCLUDE_DIRS/Python3_INCLUDE_DIRS/g
s/PYTHON_EXECUTABLE/Python3_EXECUTABLE/g
s/PYTHON_RPATH/Python3_RPATH/g
I've also renamed the CMake module to better express its purpose and for
consistency with FindLuaAndSwig.
Differential revision: https://reviews.llvm.org/D85976
In D83876 the consensus seems that LLDB should never deleted orphaned modules
implicitly. However, SBDebugger::DeleteTarget is currently doing exactly that.
This code was added in 753406221b but I don't see
any explanation in the commit, so I think we should delete it.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D83933
Right now the only places in the SB API where lldb:: ModuleSP instances are
destroyed are in SBDebugger::MemoryPressureDetected (where it's just attempted
but not guaranteed) and in SBDebugger::DeleteTarget (which will be removed in
D83933). Tests that directly create an lldb::ModuleSP and never create a target
therefore currently leak lldb::Module instances. This triggers the sanity checks
in lldbtest that make sure that the global module list is empty after a test.
This patch adds SBModule::GarbageCollectAllocatedModules as an explicit way to
clean orphaned lldb::ModuleSP instances. Also we now start calling this method
at the end of each test run and move the sanity check behind that call to make
this work. This way even tests that don't create targets can pass the sanity
check.
This fixes TestUnicodeSymbols.py when D83865 is applied (which makes that the
sanity checks actually fail the test).
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D83876
Separate the CMake logic for Lua and Python to clearly distinguish
between code specific to either scripting language and the code shared
by both.
What this patch does is:
- Move Python specific code into the bindings/python subdirectory.
- Move the Lua specific code into the bindings/lua subdirectory.
- Add the _python suffix to Python specific functions/targets.
- Fix a dependency issue that would check the binding instead of
whether the scripting language is enabled.
Note that this patch also changes where the bindings are generated,
which might affect downstream projects that check them in.
Differential revision: https://reviews.llvm.org/D85708
Currently SBTarget::LaunchSimple creates a new LaunchInfo which means it
ignores any target properties that have been set. Instead, it should
start from the target's LaunchInfo and populated the specified fields.
Differential revision: https://reviews.llvm.org/D85235
This cleanup patch unifies all methods called GetByteSize() in the
ValueObject hierarchy to return an optional, like the methods in
CompilerType do. This means fewer magic 0 values, which could fix bugs
down the road in languages where types can have a size of zero, such
as Swift and C (but not C++).
Differential Revision: https://reviews.llvm.org/D84285
This re-lands the patch with bogus :m_byte_size(0) initalizations removed.
This cleanup patch unifies all methods called GetByteSize() in the
ValueObject hierarchy to return an optional, like the methods in
CompilerType do. This means fewer magic 0 values, which could fix bugs
down the road in languages where types can have a size of zero, such
as Swift and C (but not C++).
Differential Revision: https://reviews.llvm.org/D84285
The patch was reverted 27d52cd86a because of failures in
TestWeakSymbols.py. These have now been addressed in D83552.
The original commit message was:
This function was documented to overwrite entries with D76111, which was
adding a couple of similar functions. However, this function (unlike the
functions added in that patch) was/is not actually overwriting variables
-- any pre-existing variables would get ignored.
This behavior does not seem to be intentional. In fact, before the refactor in
D41359, this function could introduce duplicate entries, which could
have very surprising effects both inside lldb and on other applications
(some applications would take the first value, some the second one; in
lldb, attempting to unset a variable could make the second variable
become active, etc.).
Overwriting seems to be the most reasonable behavior here, so change the
code to match documentation.
Differential Revision: https://reviews.llvm.org/D83306
This patch has no effect for C and C++. In more dynamic languages,
such as Objective-C and Swift GetByteSize() needs to call into the
language runtime, so it's important to pass one in where possible. My
primary motivation for this is some work I'm doing on the Swift
branch, however, it looks like we are also seeing warnings in
Objective-C that this may resolve. Everything in the SymbolFile
hierarchy still passes in nullptrs, because we don't have an execution
context in SymbolFile, since SymbolFile transcends processes.
Differential Revision: https://reviews.llvm.org/D84267
Use a weak pointer to hold on to the the underlying thread plan in
SBThreadPlan. When the process continues, all the popped ThreadPlans get
discarded, and you can’t reuse them, so you have to create them anew.
Therefore the SBThreadPlan doesn’t need to keep the ThreadPlan alive.
This fixes the cleanup error in TestThreadPlanCommands.py and
TestStepScripted.py caused by the thread plans never being deleted.
Differential revision: https://reviews.llvm.org/D84210
This patch does several things that are all closely related:
- It introduces a new YamlRecorder as a counterpart to the existing
DataRecorder. As the name suggests the former serializes data as yaml
while the latter uses raw texts or bytes.
- It introduces a new MultiProvider base class which can be backed by
either a DataRecorder or a YamlRecorder.
- It reimplements the CommandProvider in terms of the new
MultiProvider.
Finally, it adds unit testing coverage for the MultiProvider, a naive
YamlProvider built on top of the new YamlRecorder and the existing
MutliLoader.
Differential revision: https://reviews.llvm.org/D83441
Summary:
This function was documented to overwrite entries with D76111, which was
adding a couple of similar functions. However, this function (unlike the
functions added in that patch) was/is not actually overwriting variables
-- any pre-existing variables would get ignored.
This behavior does not seem to be intentional. In fact, before the refactor in
D41359, this function could introduce duplicate entries, which could
have very surprising effects both inside lldb and on other applications
(some applications would take the first value, some the second one; in
lldb, attempting to unset a variable could make the second variable
become active, etc.).
Overwriting seems to be the most reasonable behavior here, so change the
code to match documentation.
Reviewers: clayborg, wallace, jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D83306
This patch fixes a crash that is happening because of a null pointer
dereference in SBFrame.
StackFrame::GetRegisterContext says explicitly that you might not get
a valid RegisterContext back but the pointer wasn't tested before,
resulting in crashes. This should solve the issue.
rdar://54462095
Differential Revision: https://reviews.llvm.org/D83343
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch improves the error reporting for SBBreakpoint::AddName by
adding a new method `SBBreakpoint::AddNameWithErrorHandling` that returns
a SBError instead of a boolean.
This way, if the breakpoint naming failed in the backend, the client
(i.e. Xcode), will be able to report the reason of that failure to the
user.
rdar://64765461
Differential Revision: https://reviews.llvm.org/D82879
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch improves the error reporting for SBBreakpoint::AddName by
adding a new method `SBBreakpoint::AddNameWithErrorHandling` that returns
a SBError instead of a boolean.
This way, if the breakpoint naming failed in the backend, the client
(i.e. Xcode), will be able to report the reason of that failure to the
user.
rdar://64765461
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
I was holding off on this change until we moved to C++14 as to not have
to convert llvm::make_unique to std::make_unique. That happened a while
ago so here's the first patch for the API which had a bunch of raw
`new`s.
The reproducer intentionally leak every object allocated during replay,
which means that modules never get orphaned. If this were to happen for
another reason, we might not be testing what we think we are. Assert
that there are no targets left at the end of a test and that the global
module cache is empty in the non-reproducer scenario.
Differential revision: https://reviews.llvm.org/D81612
Color the error: and warning: part of the CommandReturnObject output,
similar to how an error is printed from the driver when colors are
enabled.
Differential revision: https://reviews.llvm.org/D81058
This class should've been instrumented when it landed. Whether the class
is "highly mutable" or not doesn't affect that.
With this patch TestSBEnvironment.py now passes when replayed.
This makes it possible to instrument the call for the reproducers. This
fixes TestStructuredDataAPI.py with reproducer replay.
Differential revision: https://reviews.llvm.org/D80312
The reproducers' working directory is set to the current working
directory when they are initialized. While this is not optimal, as the
cwd can change during a debug session, it has been sufficient so far.
The current approach doesn't work for the API test suite however because
dotest temporarily changes the directory to where the test's Python file
lives.
This patch adds an API to tell the reproducers what to set the CWD to.
This is a NO-OP in every mode but capture.
Differential revision: https://reviews.llvm.org/D79825
Summary:
`CalculateSyntheticValue` and `GetSyntheticValue` have a `use_synthetic` parameter
that makes the function do nothing when it's false. We obviously always pass true
to the function (or check that the value we pass is true), because there really isn't
any point calling with function with a `false`. This just removes all of this.
Reviewers: labath, JDevlieghere, davide
Reviewed By: davide
Subscribers: davide
Differential Revision: https://reviews.llvm.org/D79568
This adds an RunCommandInterpreter overload that returns an instance of
SBCommandInterpreterRunResults. The goal is to avoid having to add more
and more overloads when we need more output arguments.
Differential revision: https://reviews.llvm.org/D79120
This patch adds a new class CommandInterpreterRunResult which will be
backing the SBCommandInterpreterRunResult. It keeps track of the number
of errors as well as the result which is an enum, as proposed by Pavel
in D79120. The command interpreter now populates the results directly,
instead of its own member variables.
Differential revision: https://reviews.llvm.org/D79209
Currently, `SBCommandInterpreterRunOptions` is defined in
`SBCommandInterpreter.h`. Given that the options are always passed by
reference, a forward declaration is sufficient.
That's not the case for `SBCommandInterpreterRunResults`, which we need
for a new overload for `RunCommandInterpreter` and that returns this new
class by value. We can't include `SBCommandInterpreter.h` because
`SBCommandInterpreter::GetDebugger()` returns SBDebugger by value and
therefore needs a full definition.
This patch moves the definition of `SBCommandInterpreterRunOptions` into
a new header. In a later patch, `SBCommandInterpreterRunResults` will
be defined in there as well, solving the aforementioned problem.
Differential revision: https://reviews.llvm.org/D79115
This implements Greg's suggestion from D78825 to include "auto handle
events" and "spawn thread" in CommandInterpreterRunOptions. This change
is in preparation for adding a new overload for RunCommandInterpreter
that takes only SBCommandInterpreterRunOptions and returns
SBCommandInterpreterRunResults.
Differential revision: https://reviews.llvm.org/D79108
It seems like only the unittests are building with
BUILD_WITH_INSTALL_RPATH set to OFF. Of course when I did my last change
I only ran check-lldb-unit. Not sure why this difference exists, why
would you even install the unittest?
For the LLDB framework we do need different build and install RPATHs.
Currently that logic lives downstream. I plan to upstream that in the
near future. For now I'm just trying to make it possible to run the
test.
The install name for the Python 3 framework in Xcode is relative to
the framework's location and not the dylib itself.
@rpath/Python3.framework/Versions/3.x/Python3
This means that we need to compute the path to the Python3.framework
and use that as the RPATH instead of the usual dylib's directory.
Several SB API functions return strings using (char*, size_t) output
arguments. During capture, we serialize an empty string for the char*
because the memory can be uninitialized.
During active replay, we have custom replay redirects that ensure that
we don't override the buffer from which we're reading, but rather write
to a buffer on the heap with the given length. This is sufficient for
the active reproducer use case, where we only care about the side
effects of the API calls, not the values actually returned.
This approach does not not work for passive replay because here we
ignore all the incoming arguments, and re-execute the current function
with the arguments deserialized from the reproducer. This means that
these function will update the deserialized copy of the arguments,
rather than whatever was passed in by the SWIG wrapper.
To solve this problem, this patch extends the reproducer instrumentation
to handle this special case for passive replay. We nog ignore the
replayer in the registry and the incoming char pointer, and instead
reinvoke the current method on the deserialized class, and populate the
output argument.
Differential revision: https://reviews.llvm.org/D77759
Support passive replay as proposed in the RFC [1] on lldb-dev and
described in more detail on the lldb website [2].
This patch extends the LLDB_RECORD macros to re-invoke the current
function with arguments deserialized from the reproducer. This relies on
the function being called in the exact same order as during replay. It
uses the same mechanism to toggle the API boundary as during recording,
which guarantees that only boundary crossing calls are replayed.
Another major change is that before this patch we could ignore the
result of an API call, because we only cared about the observable
behavior. Now we need to be able to return the replayed result to the
SWIG bindings.
We reuse a lot of the recording infrastructure, which can be a little
confusing. We kept the existing naming to limit the amount of churn, but
might revisit that in a future patch.
[1] http://lists.llvm.org/pipermail/lldb-dev/2020-April/016100.html
[2] https://lldb.llvm.org/resources/reproducers.html
Differential revision: https://reviews.llvm.org/D77602
Summary:
LLDB memory-maps large source files, and at the same time, caches
all source files in the Source Cache.
On Windows, memory-mapped source files are not writeable, causing
bad user experience in IDEs (such as errors when saving edited files).
IDEs should have the ability to disable the Source Cache at LLDB
startup, so that users can edit source files while debugging.
Bug: llvm.org/PR45310
Reviewers: labath, JDevlieghere, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76804
Make it possible to capture reproducers from the API test suite. Given
the symmetry between capture and replay, this patch also adds the
necessary code for replay. For now this is a NO-OP until the
corresponding reproducer instrumentation changes land.
For more info please refer to the RFC on lldb-dev:
http://lists.llvm.org/pipermail/lldb-dev/2020-April/016100.html
Differential revision: https://reviews.llvm.org/D77588
If a plan is not private, "thread plan discard" can discard it. It would
not be hard to write reliable scripted plan if its subplans could get
removed out from under it.
Summary:
This adds support for commands created through the API to support autorepeat.
This covers the case of single word and multiword commands.
Comprehensive tests are included as well.
Reviewers: labath, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D77444
Summary:
Usually when Clang emits an error Fix-It it does two things. It emits the diagnostic and then it fixes the
currently generated AST to reflect the applied Fix-It. While emitting the diagnostic is easy to implement,
fixing the currently generated AST is often tricky. That causes that some Fix-Its just keep the AST as-is or
abort the parsing process entirely. Once the parser stopped, any Fix-Its for the rest of the expression are
not detected and when the user manually applies the Fix-It, the next expression will just produce a new
Fix-It.
This is often occurring with quickly made Fix-Its that are just used to bridge temporary API changes
and that often are not worth implementing a proper API fixup in addition to the diagnostic. To still
give some kind of reasonable user-experience for users that have these Fix-Its and rely on them to
fix their expressions, this patch adds the ability to retry parsing with applied Fix-Its multiple time to
give the normal Fix-It experience where things Clang knows how to fix are not causing actual expression
error (at least when automatically applying Fix-Its is activated).
The way this is implemented is just by having another setting in the expression options that specify how
often we should try applying Fix-Its and then reparse the expression. The default setting is still 1 for everyone
so this should not affect the speed in which we fail to parse expressions.
Reviewers: jingham, JDevlieghere, friss, shafik
Reviewed By: shafik
Subscribers: shafik, abidh
Differential Revision: https://reviews.llvm.org/D77214
SBPlatform::GetHostPlatform was missing the reproducer instrumentation
macros. Fixed by running lldb-instr on SBPlatform.cpp:
$ ./bin/lldb-instr ../llvm-project/lldb/source/API/SBPlatform.cpp
Summary:
Dumping the frame using the user-set format could cause that a debug LLDB doesn't behave as a release LLDB,
which could potentially break replaying a reproducer.
Also it's kinda strange that the frame format set by the user is used in the internal log output.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D76685
Summary:
When no arguments or environment is provided to SBTarget::LaunchSimple,
make it use the values surrently set in the target properties. You can
get the current behavior back by passing an empty array instead.
It seems like using the target defaults is a much more intuitive
behavior for those APIs. It's unllikely that anyone passed NULL/None to
this API after having set properties in order to explicitely ignore them.
One direct application of this change is within the testsuite. We have
plenty of tests calling LaunchSimple and passing None as environment.
If you passed --inferior-env to dotest.py to, for example, set
(DY)LD_LIBRARY_PATH, it wouldn't be taken into account.
Reviewers: jingham, labath, #libc_abi!
Subscribers: libcxx-commits, lldb-commits
Tags: #lldb, #libc_abi
Differential Revision: https://reviews.llvm.org/D76045
Summary: Inspired by https://reviews.llvm.org/D74636, I'm introducing a basic version of Environment in the API. More functionalities can be added as needed.
Reviewers: labath, clayborg
Subscribers: mgorny, lldb-commits, diazhector98
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76111
Summary: Inspired by https://reviews.llvm.org/D74636, I'm introducing a basic version of Environment in the API. More functionalities can be added as needed.
Reviewers: labath, clayborg
Subscribers: mgorny, lldb-commits, diazhector98
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76111
Some functions in this file only use the "target" component of an
execution context. Adjust the argument lists to reflect that.
This avoids some defensive null checks and simplifies most of the
callers.
Some tests set settings and don't clean them up, this leads to side effects in other tests.
The patch removes a global debugger instance with a per-test debugger to avoid such effects.
From what I see, lldb.DBG was needed to determine the platform before a test is run,
lldb.selected_platform is used for this purpose now. Though, this required adding a new function
to the SBPlatform interface.
Differential Revision: https://reviews.llvm.org/D74903
Summary:
This gets rid of some nesting and of the raw char* variable that caused
the memory management bug we hit recently.
This commit also removes the fallback code which should trigger when
the StopInfo provides no stop description. All currently implemented
StopInfos have a `GetDescription()` method that shouldn't return an
empty description.
Reviewers: JDevlieghere, labath, mib
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74157
This patch moves the SB API method GetExtendedCrashInformation from
SBTarget to SBProcess since it only makes sense to call this method on a
sane process which might not be the case on a SBTarget object.
It also addresses some feedbacks received after landing the first patch
for the 'crash-info' feature.
Differential Revision: https://reviews.llvm.org/D75049
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Currently, in macOS, when a process crashes, lldb halts inside the
implementation disassembly without yielding any useful information.
The only way to get more information is to detach from the process, then wait
for ReportCrash to generate a report, find the report, then see what error
message was included in it. Instead of waiting for this to happen, lldb could
locate the error_string and make it available to the user.
This patch addresses this issue by enabling the user to fetch extended
crash information for crashed processes using `process status --verbose`.
Depending on the platform, this will try to gather different crash information
into an structured data dictionnary. This dictionnary is generic and extensible,
as it contains an array for each different type of crash information.
On Darwin Platforms, lldb will iterate over each of the target's images,
extract their `__crash_info` section and generated a StructuredData::Array
containing, in each entry, the module spec, its UUID, the crash messages
and the abort cause. The array will be inserted into the platform's
`m_extended_crash_info` dictionnary and `FetchExtendedCrashInformation` will
return its JSON representation like this:
```
{
"crash-info annotations": [
{
"abort-cause": 0,
"image": "/usr/lib/system/libsystem_malloc.dylib",
"message": "main(76483,0x1000cedc0) malloc: *** error for object 0x1003040a0: pointer being freed was not allocated",
"message2": "",
"uuid": "5747D0C9-900D-3306-8D70-1E2EA4B7E821"
},
...
],
...
}
```
This crash information can also be fetched using the SB API or lldb-rpc protocol
using SBTarget::GetExtendedCrashInformation().
rdar://37736535
Differential Revision: https://reviews.llvm.org/D74657
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.
Previous attempts to land this failed on the Windows bot because there's
a dependency between the different process plugins. Apparently
ProcessWindowsCommon needs to be initialized after all other process
plugins but before ProcessGDBRemote.
Differential revision: https://reviews.llvm.org/D73067
The WASM and Hexagon plugin check the ArchType rather than the OSType,
so explicitly reject those in the DynamicLoaderStatic.
Differential revision: https://reviews.llvm.org/D74780
Generate the LLDB_PLUGIN_DECLARE macros with CMake and a def file. I'm
landing D73067 in pieces so I can bisect what exactly is breaking the
Windows bot.
Other plugins depend on DynamicLoaderDarwinKernel and which means we
cannot conditionally enable/build this plugin based on the target
platform. This means that it will be past of the list of plugins
initialized once that's autogenerated.
Summary:
All of our lookup APIs either use `CompilerDeclContext &` or `CompilerDeclContext *` semi-randomly it seems.
This leads to us constantly converting between those two types (and doing nullptr checks when going from
pointer to reference). It also leads to the confusing situation where we have two possible ways to express
that we don't have a CompilerDeclContex: either a nullptr or an invalid CompilerDeclContext (aka a default
constructed CompilerDeclContext).
This moves all APIs to use references and gets rid of all the nullptr checks and conversions.
Reviewers: labath, mib, shafik
Reviewed By: labath, shafik
Subscribers: shafik, arphaman, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74607
LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.
Differential revision: https://reviews.llvm.org/D74743
Use LLDB_PLUGIN_DEFINE_ADV to make the name of the generated initializer
match the name of the plugin. This is a step towards generating the
initializers with a def file. I'm landing this change in pieces so I can
narrow down what exactly breaks the Windows bot.
This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.
The previously landed patch got reverted because it was lacking:
(1) A plugin definition for the Objective-C language runtime,
(2) The dependency between the Static and WASM dynamic loader,
(3) Explicit initialization of ScriptInterpreterNone for lldb-test.
All issues have been addressed in this patch.
Differential revision: https://reviews.llvm.org/D73067
This patch changes the way we initialize and terminate the plugins in
the system initializer. It uses an approach similar to LLVM's
TARGETS_TO_BUILD with a def file that enumerates the plugins.
Differential revision: https://reviews.llvm.org/D73067
After the recent change that grouped some of the ABI plugins together,
those plugins ended up with multiple initializers per plugin. This is
incompatible with my proposed approach of generating the initializers
dynamically, which is why I've grouped them together in a new entry
point.
Differential revision: https://reviews.llvm.org/D74451
Move the logic for initialization and termination for DynamicLoaderMacOS
into DynamicLoaderMacOSXDYLD so that there's one initializer for the
DynamicLoaderMacOSXDYLD plugin.
Move the logic for initialization and termination for
SymbolFileDWARFDebugMap into SymbolFileDWARF so that there's one
initializer for the SymbolFileDWARF plugin.
Apparently Linux and Windows have the exact opposite behavior when it
comes to inline declarations of external functions. On Linux they're
considered to be part of the lldb_private namespace, while on Windows
they're considered to be part of the top level namespace. Somehow on
macOS, it doesn't really matter and both are fine...
At this point I don't know what to do, so I'm just adding the
LLDB_PLUGIN_DECLARE macros again as originally proposed in D74245.
This is a step towards making the initialize and terminate calls be
generated by CMake, which in turn is towards making it possible to
disable plugins at configuration time.
Differential revision: https://reviews.llvm.org/D74245
Summary:
There's a fair amount of code duplication between the different ABI plugins for
the same architecture (e.g. ABIMacOSX_arm & ABISysV_arm). Deduplicating this
code is not very easy at the moment because there is no good place where to put
the common code.
Instead of creating more plugins, this patch reduces their number by grouping
similar plugins into a single folder/plugin. This makes it easy to extract
common code to a (e.g.) base class, which can then live in the same folder.
The grouping is done based on the underlying llvm target for that architecture,
because the plugins already require this for their operation.
Reviewers: JDevlieghere, jasonmolenda, jfb
Subscribers: sdardis, nemanjai, mgorny, kristof.beyls, fedor.sergeev, kbarton, jrtc27, atanasyan, jsji, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D74138
Refactore GetStopReasonExtendedBacktraces so that the reproducer macro
is passed an instrumented copy constructor rather than the constructor
taking a ThreadCollectionSP, which is not instrumented.
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
For the methods taking a char* and a length that have a custom replayer,
ignore the incoming string in the instrumentation macro. This prevents
potentially reading garbage and blowing up the SB API log.
Some SB API methods returns strings through a char* and a length. This
is a problem for the deserializer, which considers a single type at a
time, and therefore cannot know how many bytes to allocate for the
character buffer.
We can solve this problem by implementing a custom replayer, which
ignores the passed-in char* and allocates a buffer of the correct size
itself, before invoking the original API method or function.
This patch adds three new macros to register a custom replayer for
methods that take a char* and a size_t. It supports arbitrary return
values (some functions return a bool while others return a size_t).
This patch has a couple of outstanding issues. The test is not python3
compatible, and it also seems to fail with python2 (at least under some
circumstances) due to an overambitious assertion.
This reverts the patch as well as subsequent fixup attempts:
014ea93376,
f5f70d1c8f.
4697e701b8.
5c15e8e682.
3ec28da6d6.
When trying to get the stop reason description using the SB API, the
buffer fetched was not null-terminated causing failures on the sanitized bot.
This patch should address those failures.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
The reproducer instrumentation cannot automatically serialize and
deserialize void* arguments. Currently we deal with this by explicitly
preventing these methods from being instrumented. This has the undesired
side effect of breaking replay when that method returns a value later
used by another SB API call.
The solution is to change our approach and instrument these methods.
Instead of using the DUMMY macro, we just make (de)serialization of the
void pointer a NOOP and always return a nullptr.
Currently SBFile isn't really instrumented, which was causing trouble
when capturing and replaying the Python test suite. The class is
particularly tricky because one of its constructors takes a FileSP which
isn't instrumented. Until we have proper shadowing in place, we'll
simply always record a nullptr.
Differential revision: https://reviews.llvm.org/D73992
I previously removed the code in ValueObject::GetExpressionPath that
took advantage of the parameter `qualify_cxx_base_classes`. As a result,
this is now unused and can be removed.
Summary:
This change represents the move of ClangASTImporter, ClangASTMetadata,
ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and
TypeSystemClang from lldbSource to lldbPluginExpressionParserClang.h
This explicitly removes knowledge of clang internals from lldbSymbol,
moving towards a more generic core implementation of lldb.
Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafik
Subscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73661
GetStopDescription writes to a const char* with a given length. However,
the reproducer instrumentation serialized the char pointer and length
separately.
To serialize the string, we naively look for the first null byte to
determine its length. This can lead to the method overwriting the input
buffer when the assumed string length is smaller than the actual number
of bytes written by GetStopDescription.
The real solution is to have a custom serializer that takes both
arguments into account. However, given that these are output parameters,
they don't affect replay. If the string is passed as input later, it's
is recorded as such. Therefore I've replaced the instrumentation macro
with LLDB_RECORD_DUMMY which skips the serialization.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
When a thread stops, this checks depending on the platform if the top frame is
an abort stack frame. If so, it looks for an assert stack frame in the upper
frames and set it as the most relavant frame when found.
To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a
"cooked" stop reason description. When the thread is about to stop, it checks
if the current frame is recognized, and if so, it fetches the recognized frame's
attributes and applies them.
rdar://58528686
Differential Revision: https://reviews.llvm.org/D73303
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
AppleObjCRuntime is the main entry point to the plugin with the same
name. This is part of a greater refactoring to auto generate the
initializers. NFC.
Differential revision: https://reviews.llvm.org/D73121
PlatformMacOSX is the main entry point to the plugin with the same name.
This is part of a greater refactoring to auto generate the initializers.
Differential revision: https://reviews.llvm.org/D73116
Add a flag which always generates a reproducer when normally it would be
discarded. This is meant for testing purposes to capture a debugger
session without modification the session itself.
Summary:
This is the first in a series of patches to enable LLDB debugging of
WebAssembly targets.
Current versions of Clang emit (partial) DWARF debug information in WebAssembly
modules and we can leverage this debug information to give LLDB the ability to
do source-level debugging of Wasm code that runs in a WebAssembly engine.
A way to do this could be to use the remote debugging functionalities provided
by LLDB via the GDB-remote protocol. Remote debugging can indeed be useful not
only to connect a debugger to a process running on a remote machine, but also to
connect the debugger to a managed VM or script engine that runs locally,
provided that the engine implements a GDB-remote stub that offers the ability to
access the engine runtime internal state.
To make this work, the GDB-remote protocol would need to be extended with a few
Wasm-specific custom query commands, used to access aspects of the Wasm engine
state (like the Wasm memory, Wasm local and global variables, and so on).
Furthermore, the DWARF format would need to be enriched with a few Wasm-specific
extensions, here detailed: https://yurydelendik.github.io/webassembly-dwarf.
This CL introduce classes **ObjectFileWasm**, a file plugin to represent a Wasm
module loaded in a debuggee process. It knows how to parse Wasm modules and
store the Code section and the DWARF-specific sections.
Reviewers: jasonmolenda, clayborg, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71575
I modified the SBAPI under the assumption that nobody was using the old
API yet. However, that turns out to be false. So instead of adding the
deafault argument I've reintroduced the old API and made the new one an
overload.
Summary:
Motivation: When formatting an array of typedefed chars, we would like to display the array as a string.
The string formatter currently does not trigger because the formatter lookup does not resolve typedefs for array elements (this behavior is inconsistent with pointers, for those we do look through pointee typedefs). This patch tries to make the array formatter lookup somewhat consistent with the pointer formatter lookup.
Reviewers: teemperor, clayborg
Reviewed By: teemperor, clayborg
Subscribers: clayborg, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72133
All the code required to generate the language bindings for Python and
Lua lives under scripts, even though the majority of this code aren't
scripts at all, and surrounded by scripts that are totally unrelated.
I've reorganized these files and moved everything related to the
language bindings into a new top-level directory named bindings. This
makes the corresponding files self contained and much more discoverable.
Differential revision: https://reviews.llvm.org/D72437
Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`.
Reviewers: shafik, JDevlieghere, labath
Reviewed By: labath
Subscribers: arphaman, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72161
Summary:
lib/python2.7/dist-packages/lldb/_lldb.so is a symlink to lib/liblldb.so,
which depends on lib/libLLVM*.so (-DBUILD_SHARED_LIBS=ON) or lib/libLLVM-10git.so
(-DLLVM_LINK_LLVM_DYLIB=ON). Add an additional rpath `$ORIGIN/../../../../lib` so
that _lldb.so can be loaded from Python.
This fixes an import error from lib/python2.7/dist-packages/lldb/__init__.py
from . import _lldb
ImportError: libLLVMAArch64CodeGen.so.10git: cannot open shared object file: No such file or directory
The following configurations will work:
* -DBUILD_SHARED_LIBS=ON
* -DBUILD_SHARED_LIBS=OFF -DLLVM_LINK_LLVM_DYLIB=ON
* -DBUILD_SHARED_LIBS=OFF -DLLVM_LINK_LLVM_DYLIB=ON -DCLANG_LINK_CLANG_DYLIB=ON
(-DCLANG_LINK_CLANG_DYLIB=ON depends on -DLLVM_LINK_LLVM_DYLIB=ON)
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D71800
PYTHON_LIBRARIES is the canonical variable set by FindPythonLibs while
PYTHON_LIBRARY is an implementation detail. This replaces the uses of
the latter with the former.
This is a half-implemented feature that as far as we can tell was
never used by anything since its original inclusion in 2014. This
patch removes it to make remaining the code easier to understand.
Differential Revision: https://reviews.llvm.org/D71310
As suggested by Pavel in a code review:
> Can we replace this (and maybe python too, while at it) with a
> Host/Config.h entry? A global definition means that one has to
> recompile everything when these change in any way, whereas in
> practice only a handful of files need this..
Differential revision: https://reviews.llvm.org/D71280
When running the test suite with always capture on, a handful of tests
are failing because they have multiple targets and therefore multiple
GDB remote connections. The current reproducer infrastructure is capable
of dealing with that.
This patch reworks the GDB remote provider to support multiple GDB
remote connections, similar to how the reproducers support shadowing
multiple command interpreter inputs. The provider now keeps a list of
packet recorders which deal with a single GDB remote connection. During
replay we rely on the order of creation to match the number of packets
to the GDB remote connection.
Differential revision: https://reviews.llvm.org/D71105
Summary:
Using a BreakpointList corrupts the breakpoints' IDs because
BreakpointList::Add sets the ID, so use a vector instead, and
update the signature to return the vector wrapped in an
llvm::Expected which can propagate any error from the inner
call to StringIsBreakpointName.
Note that, despite the similar name, SBTarget::FindBreakpointsByName
doesn't suffer the same problem, because it uses a SBBreakpointList,
which is more like a BreakpointIDList than a BreakpointList under the
covers.
Add a check to TestBreakpointNames that, without this fix, notices the
ID getting mutated and fails.
Reviewers: jingham, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70907
To ensure a reproducer works correctly, the version of LLDB used for
capture and replay must match. Right now the reproducer already contains
the LLDB version. However, this is purely informative. LLDB will happily
replay a reproducer generated with a different version of LLDB, which
can cause subtle differences.
This patch adds a version check which compares the current LLDB version
with the one in the reproducer. If the version doesn't match, LLDB will
refuse to replay. It also adds an escape hatch to make it possible to
still replay the reproducer without having to mess with the recorded
version. This might prove useful when you know two versions of LLDB
match, even though the version string doesn't. This behavior is
triggered by passing a new flag -reproducer-skip-version-check to the
lldb driver.
Differential revision: https://reviews.llvm.org/D70934
Summary:
CompileUnit is a complicated class. Having it be implicitly convertible
to a FileSpec makes reasoning about it even harder.
This patch replaces the inheritance by a simple member and an accessor
function. This avoid the need for casting in places where one needed to
force a CompileUnit to be treated as a FileSpec, and does not add much
verbosity elsewhere.
It also fixes a bug where we were wrongly comparing CompileUnit& and a
CompileUnit*, which compiled due to a combination of this inheritance
and the FileSpec*->FileSpec implicit constructor.
Reviewers: teemperor, JDevlieghere, jdoerfert
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70827
Summary:
I found the above named method hard to read because it had
a) many nested blocks,
b) one return statement at the end with some logic involved,
c) a duplicated while-loop with just small differences in it.
I decided to refactor this function by employing an early exit strategy.
In order to capture the logic in the return statement and to not have it
repeated more than once I chose to implement a very small lamda function
that captures all the variables it needs.
I also replaced the two while-loops with just one.
This is a non-functional change (NFC).
Reviewers: jdoerfert, teemperor
Reviewed By: teemperor
Subscribers: labath, teemperor, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70774
Summary:
I found the above named method hard to read because it had
a) many nested blocks and
b) one return statement at the end with some logic involved.
I decided to refactor this function by employing an early exit strategy.
In order to capture the logic in the return statement and to not have it
repeated more than once I chose to implement a very small lamda function
that captures all the variables it needs.
This is a non-functional change (NFC).
Reviewers: jdoerfert
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70774
Summary:
Adds support for doing range-based for-loops on LLDB's VariableList and
modernises all the index-based for-loops in LLDB where possible.
Reviewers: labath, jdoerfert
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70668
This patch hooks the reproducer infrastructure with the signal handlers.
When lldb crashes with reproducers capture enabled, it will now generate
the reproducer and print a short message the standard out. This doesn't
affect the pretty stack traces, which are still printed before.
This patch also introduces a new reproducer sub-command that
intentionally raises a given signal to test the reproducer signal
handling.
Currently the signal handler is doing too much work. Instead of copying
over files into the reproducers in the signal handler, we should
re-invoke ourselves with a special command line flag that looks at the
VFS mapping and performs the copy.
This is a NO-OP when reproducers are disabled.
Differential revision: https://reviews.llvm.org/D70474
This fixes the following warning for developers:
Target 'liblldb' was changed to a FRAMEWORK sometime after install(). This
may result in the wrong install DESTINATION. Set the FRAMEWORK property
earlier.
The solution is to pass the FRAMEWORK flag to add_lldb_library and set
the target property before install(). For now liblldb is the only
customer.
For example, it is pretty easy to write a breakpoint command that implements "stop when my caller is Foo", and
it is pretty easy to write a breakpoint command that implements "stop when my caller is Bar". But there's no
way to write a generic "stop when my caller is..." function, and then specify the caller when you add the
command to a breakpoint.
With this patch, you can pass this data in a SBStructuredData dictionary. That will get stored in
the PythonCommandBaton for the breakpoint, and passed to the implementation function (if it has the right
signature) when the breakpoint is hit. Then in lldb, you can say:
(lldb) break com add -F caller_is -k caller_name -v Foo
More generally this will allow us to write reusable Python breakpoint commands.
Differential Revision: https://reviews.llvm.org/D68671
This patch removes the size_t return value and the append parameter
from the remainder of the Find.* functions in LLDB's internal API. As
in the previous patches, this is motivated by the fact that these
parameters aren't really used, and in the case of the append parameter
were frequently implemented incorrectly.
Differential Revision: https://reviews.llvm.org/D69119
llvm-svn: 375160
POSIX says FILE is a typedef to a structure containing information about
a file. The structure is unspecified, i.e. it may be an incomplete type, as is the case on musl
(`struct _IO_FILE` is an implementation detail that is not exposed).
`LLDB_RECORD_METHOD(..., (FILE *), ...)` transitively uses sizeof(FILE)
and requires the structure to be complete. Change it to
LLDB_RECORD_DUMMY to fix the build failure on musl (regression of
D57475).
Reviewed By: JDevlieghere, labath, lawrence_danna
Differential Revision: https://reviews.llvm.org/D68872
llvm-svn: 375072
Summary:
This patch removes FILE* and replaces it with SBFile and FileSP the
SWIG interface for `SBStream.i`. And this is the last one. With
this change, nothing in the python API will can access a FILE* method
on the C++ side.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68960
llvm-svn: 374924
Summary:
This makes SBFile::GetFile public and adds a SWIG typemap to convert
the result back into a python native file.
If the underlying File itself came from a python file, it is returned
identically. Otherwise a new python file object is created using
the file descriptor.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68737
llvm-svn: 374911
oops! I cherry-picked rL374820 thinking it was completely
independent of D68737, but it wasn't. It makes an incidental
use of SBFile::GetFile, which is introduced there, so I broke the
build.
The docs say you can commit without review for "obvious". I think
this qualifies. If this kind of fix isn't considered obvious, let
me know and I'll revert instead.
Fixes: rL374820
llvm-svn: 374825
Summary:
This patch replaces the FILE* python bindings for SBInstruction and
SBInstructionList and replaces them with the new, safe SBFile and FileSP
bindings.
I also re-enable `Test_Disassemble_VST1_64`, because now we can use
the file bindings as an additional test of the disassembler, and we
can use the disassembler test as a test of the file bindings.
The bugs referred to in the comments appear to have been fixed. The
radar is closed now and the bugzilla bug does not reproduce with the
instructions given.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68890
llvm-svn: 374820
Summary:
This patch re-types everywhere that passes a File::OpenOptions
as a uint32_t so it actually uses File::OpenOptions.
It also converts some OpenOptions related functions that fail
by returning 0 or NULL into llvm::Expected
split off from https://reviews.llvm.org/D68737
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68853
llvm-svn: 374817
Summary:
This patch adds FileSP and SBFile versions of the API methods
ReportEventState and HandleProcessEvent. It points the SWIG
wrappers at these instead of the ones that use FILE* streams.
Reviewers: JDevlieghere, jasonmolenda, labath, jingham
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68546
llvm-svn: 374816
Summary:
There a a few call sites that use FILE* which are easy to
fix without disrupting anything else.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: JDevlieghere, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68444
llvm-svn: 374239
Tatyana Krasnukha