| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Errors will get "error:" prefixes automatically so this is not needed.
|
|
(again) (#128156)
This reverts commit
https://github.com/llvm/llvm-project/commit/87b7f63a117c340a6d9ca47959335fd7ef6c7ad2,
reapplying
https://github.com/llvm/llvm-project/commit/7e66cf74fb4e6a103f923e34700a7b6f20ac2a9b
with a small (and probably temporary)
change to generate more debug info to help with diagnosing buildbot
issues.
|
|
Current state in scripted process expects [all the
modules](https://github.com/llvm/llvm-project/blob/912b154f3a3f8c3cebf5cc5731fd8b0749762da5/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp#L498)
passed into "get_loaded_images" to load successfully else none of them
load. Even if a module loads fine, [but has already been
appended](https://github.com/llvm/llvm-project/blob/912b154f3a3f8c3cebf5cc5731fd8b0749762da5/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp#L495)
it still fails. This is restrictive and does not help our usecase.
**Usecase**: We have a parent scripted process using coredump +
tombstone.
1) Scripted process uses child elf-core process to read memory dump
2) Uses tombstones to pass thread names and modules.
We do not know whether the modules will be successfully downloaded
before creating the scripted process. We use [python module
callbacks](https://github.com/llvm/llvm-project/blob/a57e58dbfaae0e86eb5cafeddf8b598f14b96e36/lldb/source/Target/Platform.cpp#L1593)
to download a module from symbol server at LLDB load time when the
scripted process is being created. The issue is that if one of the
symbol is not found from the list specified in tombstone, none of the
modules load in scripted process. Even if we ensure symbols are present
in symbol server before creating the scripted process, if the load
address is wrong or if the module is already appended, all module loads
are skipped.
**Solution**: Pass in a custom boolean option arg for every module from
python scripted process plugin which will indicate whether to ignore the
module load error. This will provide the flexibility to user for loading
the successfully fetched modules into target while ignoring the failed
ones
---------
Co-authored-by: rchamala <rachamal@fb.com>
|
|
This reverts commit 7e66cf74fb4e6a103f923e34700a7b6f20ac2a9b.
Breaking green dragon:
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/19569/testReport/junit/lldb-api/functionalities_reverse-execution/TestReverseContinueWatchpoints_py/
|
|
This reverts commit a774de807e56c1147d4630bfec3110c11d41776e.
This is the same changes as last time, plus:
* We load the binary into the target object so that on Windows, we can
resolve the locations of the functions.
* We now assert that each required breakpoint has at least 1 location,
to prevent an issue like that in the future.
* We are less strict about the unsupported error message, because it
prints "error: windows" on Windows instead of "error: gdb-remote".
|
|
(#123906)"" (#125091)
Reverts llvm/llvm-project#123945
Has failed on the Windows on Arm buildbot:
https://lab.llvm.org/buildbot/#/builders/141/builds/5865
```
********************
Unresolved Tests (2):
lldb-api :: functionalities/reverse-execution/TestReverseContinueBreakpoints.py
lldb-api :: functionalities/reverse-execution/TestReverseContinueWatchpoints.py
********************
Failed Tests (1):
lldb-api :: functionalities/reverse-execution/TestReverseContinueNotSupported.py
```
Reverting while I reproduce locally.
|
|
(#123945)
This reverts commit 22561cfb443267905d4190f0e2a738e6b412457f and fixes
b7b9ccf44988edf49886743ae5c3cf4184db211f (#112079).
The problem is that x86_64 and Arm 32-bit have memory regions above the
stack that are readable but not writeable. First Arm:
```
(lldb) memory region --all
<...>
[0x00000000fffcf000-0x00000000ffff0000) rw- [stack]
[0x00000000ffff0000-0x00000000ffff1000) r-x [vectors]
[0x00000000ffff1000-0xffffffffffffffff) ---
```
Then x86_64:
```
$ cat /proc/self/maps
<...>
7ffdcd148000-7ffdcd16a000 rw-p 00000000 00:00 0 [stack]
7ffdcd193000-7ffdcd196000 r--p 00000000 00:00 0 [vvar]
7ffdcd196000-7ffdcd197000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
```
Compare this to AArch64 where the test did pass:
```
$ cat /proc/self/maps
<...>
ffffb87dc000-ffffb87dd000 r--p 00000000 00:00 0 [vvar]
ffffb87dd000-ffffb87de000 r-xp 00000000 00:00 0 [vdso]
ffffb87de000-ffffb87e0000 r--p 0002a000 00:3c 76927217 /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1
ffffb87e0000-ffffb87e2000 rw-p 0002c000 00:3c 76927217 /usr/lib/aarch64-linux-gnu/ld-linux-aarch64.so.1
fffff4216000-fffff4237000 rw-p 00000000 00:00 0 [stack]
```
To solve this, look up the memory region of the stack pointer (using
https://lldb.llvm.org/resources/lldbgdbremote.html#qmemoryregioninfo-addr)
and constrain the read to within that region. Since we know the stack is
all readable and writeable.
I have also added skipIfRemote to the tests, since getting them working
in that context is too complex to be worth it.
Memory write failures now display the range they tried to write, and
register write errors will show the name of the register where possible.
The patch also includes a workaround for a an issue where the test code
could mistake an `x` response that happens to begin with an `O` for an
output packet (stdout). This workaround will not be necessary one we
start using the [new
implementation](https://discourse.llvm.org/t/rfc-fixing-incompatibilties-of-the-x-packet-w-r-t-gdb/84288)
of the `x` packet.
---------
Co-authored-by: Pavel Labath <pavel@labath.sk>
|
|
Reverts llvm/llvm-project#112079 due to failures on the arm bot.
|
|
This commit adds support for a
`SBProcess::ContinueInDirection()` API. A user-accessible command for
this will follow in a later commit.
This feature depends on a gdbserver implementation (e.g. `rr`) providing
support for the `bc` and `bs` packets. `lldb-server` does not support
those packets, and there is no plan to change that. For testing
purposes, this commit adds a Python implementation of *very limited*
record-and-reverse-execute functionality, implemented as a proxy between
lldb and lldb-server in `lldbreverse.py`. This should not (and in
practice cannot) be used for anything except testing.
The tests here are quite minimal but we test that simple breakpoints and
watchpoints work as expected during reverse execution, and that
conditional breakpoints and watchpoints work when the condition calls a
function that must be executed in the forward direction.
|
|
Reverting this again; I added a commit which added @skipIfDarwin
markers to the TestReverseContinueBreakpoints.py and
TestReverseContinueNotSupported.py API tests, which use lldb-server
in gdbserver mode which does not work on Darwin. But the aarch64 ubuntu
bot reported a failure on TestReverseContinueBreakpoints.py,
https://lab.llvm.org/buildbot/#/builders/59/builds/6397
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/reverse-execution/TestReverseContinueBreakpoints.py", line 63, in test_reverse_continue_skip_breakpoint
self.reverse_continue_skip_breakpoint_internal(async_mode=False)
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/reverse-execution/TestReverseContinueBreakpoints.py", line 81, in reverse_continue_skip_breakpoint_internal
self.expect(
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2372, in expect
self.runCmd(
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1002, in runCmd
self.assertTrue(self.res.Succeeded(), msg + output)
AssertionError: False is not true : Process should be stopped due to history boundary
Error output:
error: Process must be launched.
This reverts commit 4f297566b3150097de26c6a23a987d2bd5fc19c5.
|
|
This commit only adds support for the
`SBProcess::ReverseContinue()` API. A user-accessible command for this
will follow in a later commit.
This feature depends on a gdbserver implementation (e.g. `rr`) providing
support for the `bc` and `bs` packets. `lldb-server` does not support
those packets, and there is no plan to change that. So, for testing
purposes, `lldbreverse.py` wraps `lldb-server` with a Python
implementation of *very limited* record-and-replay functionality for use
by *tests only*.
The majority of this PR is test infrastructure (about 700 of the 950
lines added).
|
|
This reverts commit d5e1de6da96c1ab3b8cae68447e8ed3696a7006e.
|
|
This commit only adds support for the
`SBProcess::ReverseContinue()` API. A user-accessible command for this
will follow in a later commit.
This feature depends on a gdbserver implementation (e.g. `rr`) providing
support for the `bc` and `bs` packets. `lldb-server` does not support
those packets, and there is no plan to change that. So, for testing
purposes, `lldbreverse.py` wraps `lldb-server` with a Python
implementation of *very limited* record-and-replay functionality for use
by *tests only*.
The majority of this PR is test infrastructure (about 700 of the 950
lines added).
|
|
This patch removes all of the Set.* methods from Status.
This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.
This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()
Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form
` ResultTy DoFoo(Status& error)
`
to
` llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?
The interesting changes are in Status.h and Status.cpp, all other
changes are mostly
` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.
|
|
We need to generate events when finalizing, or we won't know that we
succeeded in stopping the process to detach/kill. Instead, we stall and
then after our 20 interrupt timeout, we kill the process (even if we
were supposed to detach) and exit.
OTOH, we have to not generate events when the Process is being
destructed because shared_from_this has already been torn down, and
using it will cause crashes.
|
|
This patch should fix a test failure in
`Expr/TestIRMemoryMapWindows.test`:
https://lab.llvm.org/buildbot/#/builders/219/builds/6786
The problem here is that since 7991412 landed, all the
`ScriptInterpreter::CreateScripted*Interface` now return a `nullptr`
when using the base `ScriptInterpreter` instance, instead of
`ScriptInterpreterPython` for instance.
This nullptr is actually well handled in the various places where we
create a Scripted Interface, however, because of the way to instanciate
a process, the process plugin manager have to iterate over every process
plugin and call the `CreateInstance` static function that should
instanciate the right object.
So in the ScriptedProcess case, because we are getting a `nullptr` when
trying to create a `ScriptedProcessInterface`, we try to discard the
process object, which calls the Process destructor, which in turns calls
the `ScriptedProcess` plugin `IsAlive` method. That method will fire an
assertion if the scripted interface pointer is not allocated.
This patch address that issue by setting a flag when destroying the
ScriptedProcess object, and checks that flag when calling `IsAlive`.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
|
|
This patch should fix some assertion that started getting hit after f22d82c.
That commit changed the scripted object plugin creation to use
`llvm::Expected<T>` as a return type to enforce error handling, however
I forgot to handle the error which caused the assert.
The interesting part about this, is that since that assert was triggered
in the ScriptedProcess constructor (where the `llvm::Error` wasn't
handled), that impacted every test that launched any kind of process,
since the process plugin manager would eventually also iterate over the
`ScriptedProcess::Create` factory method.
This patch should fix the assertions by handling the errors.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
|
|
This patch changes the way plugin objects used with Scripted Interfaces
are created.
Instead of implementing a different SWIG method to create the object for
every scripted interface, this patch makes the creation more generic by
re-using some of the ScriptedPythonInterface templated Dispatch code.
This patch also improves error handling of the object creation by
returning an `llvm::Expected`.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
|
|
This patch attempts to fix a dead lock when loading modules in a Scripted
Process.
This issue was triggered by loading the modules after the process did resume,
but before the process actually stop, causing the language runtime mutex to
be locked by a separate thread, responsible to unwind the stack (using
the runtime unwind plan), while the module loading thread was trying to
notify the runtimes of the newly loaded module.
To address that, this patch moves the module loading logic to be done before
sending the stop event, to prevent the dead lock situation described above.
Differential Revision: https://reviews.llvm.org/D154649
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
|
|
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>
|
|
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 support for breakpoint setting to Scripted Processes.
For now, Scripted Processes only support setting software breakpoints.
When doing interactive scripted process debugging, it makes use of the
memory writing capability to write the trap opcodes in the memory of the
driving process. However the real process' target doesn't keep track of
the breakpoints that got added by the scripted process. This is a design
that we might need to change in the future, since we'll probably need to
do some book keeping to handle breakpoints that were set by different
scripted processes.
Differential Revision: https://reviews.llvm.org/D145296
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 should fix an assertion that causes some test failures:
https://ci.swift.org/view/LLDB/job/llvm-org-lldb-release-debuginfo/3587/console
This was caused by the changes introduces in `88f409194d5a` where we
replaced `DidLaunch` by `DidResume` in the `ScriptedProcess` class.
However, by the time we resume the process, the pid should be already
set. To address this, this patch brings back `DidLaunch` which will
initialize the ScriptedProcess pid with a placeholder value. That value
will be updated in `DidResume` to the final pid.
Note, this 2 stage PID initialization is necessary sometimes, when the
scripted process gets stopped at entry (launch) and gets assigned an
object that contains the PID value. In this case, we need to update the
PID when we resume the process after we've stopped at entry.
This also replaces the default scripted process id to an arbitrary
number (42) since the current value (0) is considered invalid.
Differential Revision: https://reviews.llvm.org/D148153
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
Now that we can pass Python objects to the scripted process instance, we
don't need to parse the crashlog twice anymore.
Differential revision: https://reviews.llvm.org/D148063
|
|
../llvm-project/lldb/include/lldb/Interpreter/ScriptedProcessInterface.h:61:12:
warning: implicit conversion from 'unsigned long long' to 'size_t' (aka 'unsigned int')
changes value from 18446744073709551615 to 4294967295 [-Wconstant-conversion]
../llvm-project/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp:275:39:
warning: result of comparison of constant 18446744073709551615 with expression
of type 'size_t' (aka 'unsigned int') is always false [-Wtautological-constant-out-of-range-compare]
This happens because size_t on 32 bit is 32 bit, but LLDB_INVALID_OFFSET is
UINT64_MAX. Return lldb::offset_t instead, which is 64 bit everywhere.
DoWriteMemory still returns size_t but this is because every other
Process derived thing does that. As long as the failure check works I think
it should be fine.
Reviewed By: mib
Differential Revision: https://reviews.llvm.org/D146124
|
|
This reverts commit cfe06f495beb520ab366957d1108bb80c7c92832.
|
|
This reverts commit 3c33d72e7fa83beb8a9b39fb3b8ecf4ee00c697d.
|
|
This patch moves `ScriptedMetadata.h` from the `Interpreter` directory to
the `Utility` sub-directory since `ProcessInfo.h` depends on it.
It also gets rid of the unused `OptionGroupPythonClassWithDict`
constructor for `ScriptedMetadata` which would address the layering
violation.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This patch adds support for breakpoint setting to Scripted Processes.
For now, Scripted Processes only support setting software breakpoints.
When doing interactive scripted process debugging, it makes use of the
memory writing capability to write the trap opcodes in the memory of the
driving process. However the real process' target doesn't keep track of
the breakpoints that got added by the scripted process. This is a design
that we might need to change in the future, since we'll probably need to
do some book keeping to handle breakpoints that were set by different
scripted processes.
Differential Revision: https://reviews.llvm.org/D145296
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 adds memory writing capabilities to the Scripted Process plugin.
This allows to user to get a target address and a memory buffer on the
python scripted process implementation that the user can make processing
on before performing the actual write.
This will also be used to write trap instruction to a real process
memory to set a breakpoint.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This patch adds process attach capabilities to the ScriptedProcess
plugin. This doesn't really expects a PID or process name, since the
process state is already script, however, this allows to create a
scripted process without requiring to have an executuble in the target.
In order to do so, this patch also turns the scripted process related
getters and setters from the `ProcessLaunchInfo` and
`ProcessAttachInfo` classes to a `ScriptedMetadata` instance and moves
it in the `ProcessInfo` class, so it can be accessed interchangeably.
This also adds the necessary SWIG wrappers to convert the internal
`Process{Attach,Launch}InfoSP` into a `SB{Attach,Launch}Info` to pass it
as argument the scripted process python implementation and convert it
back to the internal representation.
rdar://104577406
Differential Revision: https://reviews.llvm.org/D143104
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This patch should address a bug when a user have multiple scripted
processes in the same debugging session.
In order for the scripted process plugin to be able to call into the
scripted object instance methods to fetch the necessary data to
reconstruct its state, the scripted process plugin calls into a
scripted process interface, that has a reference to the created script
object instance.
However, prior to this patch, we only had a single instance of the
scripted process interface, living the script interpreter. So every time
a new scripted process plugin was created, it would overwrite the script
object instance that was held by the single scripted process interface
in the script interpreter.
That would cause all the method calls made to the scripted process
interface to be dispatched by the last instanciated script object
instance, which is wrong.
In order to prevent that, this patch moves the scripted process
interface reference to be help by the scripted process plugin itself.
rdar://104882562
Differential Revision: https://reviews.llvm.org/D143308
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This patch introduces a new `GetScriptedImplementation` method to the
SBProcess class in the SBAPI. It will allow users of Scripted Processes to
fetch the scripted implementation object from to script interpreter to be
able to interact with it directly (without having to go through lldb).
This allows to user to perform action that are not specified in the
scripted process interface, like calling un-specified methods, but also
to enrich the implementation, by passing it complex objects.
Differential Revision: https://reviews.llvm.org/D143236
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This patch enhances queue support in Scripted Processes.
Scripted Threads could already report their queue name if they had one,
but this information was only surfaced when getting the process and
thread status.
However, no queue was create and added to the scripted process queue
list. This patch improves that by creating a queue from the scripted
thread queue name. For now, it uses an invalid queue id, since the
scripted thread doesn't expose this capability yet, but this could
easily be supported if the queue id information is available.
rdar://98844004
Differential Revision: https://reviews.llvm.org/D139853
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This patch moves the ScriptedProcessInfo class out of the
ScriptedProcess and hoist it as a standalone interpreter class, so it can be
reused with the Scripted Platform.
Differential Revision: https://reviews.llvm.org/D139247
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.
Differential Revision: https://reviews.llvm.org/D141298
|
|
This reverts commit fbaf48be0ff6fb24b9aa8fe9c2284fe88a8798dd.
This has broken all LLDB buildbots:
https://lab.llvm.org/buildbot/#/builders/68/builds/44990
https://lab.llvm.org/buildbot/#/builders/96/builds/33160
|
|
Removing .c_str() has a semantics difference, but the use scenarios
likely do not matter as we don't have NUL in the strings.
|
|
For an exception crashlog, the thread backtraces aren't usually very helpful
and instead, developpers look at the "Application Specific Backtrace" that
was generated by `objc_exception_throw`.
LLDB could already parse and symbolicate these Application Specific Backtraces
for regular textual-based crashlog, so this patch adds support to parse them
in JSON crashlogs, and materialize them a HistoryThread extending the
crashed ScriptedThread.
This patch also includes the Application Specific Information messages
as part of the process extended crash information log. To do so, the
ScriptedProcess Python interface has a new GetMetadata method that
returns an arbitrary dictionary with data related to the process.
rdar://93207586
Differential Revision: https://reviews.llvm.org/D126260
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
Make constructors of the Process and its subclasses class protected,
to prevent accidentally constructing Process on stack when it could be
afterwards accessed via a shared_ptr (since it uses
std::enable_shared_from_this<>).
The only place where a stack allocation was used were unittests,
and fixing them via declaring an explicit public constructor
in the respective mock classes is trivial.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D131275
|
|
With Scripted Processes, in order to create scripted threads, the blueprint
provides a dictionary that have each thread index as the key with the respective
thread instance as the pair value.
In Python, this is fine because a dictionary key can be of any type including
integer types:
```
>>> {1: "one", 2: "two", 10: "ten"}
{1: 'one', 2: 'two', 10: 'ten'}
```
However, when the python dictionary gets bridged to C++ we convert it to a
`StructuredData::Dictionary` that uses a `std::map<ConstString, ObjectSP>`
for storage.
Because `std::map` is an ordered container and ours uses the `ConstString`
type for keys, the thread indices gets converted to strings which makes the
dictionary sorted alphabetically, instead of numerically.
If the ScriptedProcess has 10 threads or more, it causes thread “10”
(and higher) to be after thread “1”, but before thread “2”.
In order to solve this, this sorts the thread info dictionary keys
numerically, before iterating over them to create ScriptedThreads.
rdar://90327854
Differential Revision: https://reviews.llvm.org/D122429
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This patch introduces a new way to load modules programatically with
Scripted Processes. To do so, the scripted process blueprint holds a
list of dictionary describing the modules to load, which their path or
uuid, load address and eventually a slide offset.
LLDB will fetch that list after launching the ScriptedProcess, and
iterate over each entry to create the module that will be loaded in the
Scripted Process' target.
The patch also refactors the StackCoreScriptedProcess test to stop
inside the `libbaz` module and make sure it's loaded correctly and that
we can fetch some variables from it.
rdar://74520238
Differential Revision: https://reviews.llvm.org/D120969
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This patch introduces a new type of ScriptedProcess: CrashLogScriptedProcess.
It takes advantage of lldb's crashlog parsers and Scripted Processes to
reconstruct a static debugging session with symbolicated stackframes, instead
of just dumping out everything in the user's terminal.
The crashlog command also has an interactive mode that only provide a
very limited experience. This is why this patch removes all the logic
for this interactive mode and creates CrashLogScriptedProcess instead.
This will fetch and load all the libraries that were used by the crashed
thread and re-create all the frames artificially.
rdar://88721117
Differential Revision: https://reviews.llvm.org/D119501
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This patch adds the ability for ScriptedThread to load artificial stack
frames. To do so, the interpreter instance can create a list that will
contain the frame index and its pc address.
Then, when the Scripted Process plugin stops, it will refresh its
Scripted Threads state by invalidating their register context and load
to list from the interpreter object and reconstruct each frame.
This patch also removes all of the default implementation for
`get_stackframes` from the derived ScriptedThread classes, and add the
interface code for the Scripted Thread Interface.
rdar://88721095
Differential Revision: https://reviews.llvm.org/D119388
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
This reverts commit 0df522969a7a0128052bd79182c8d58e00556e2f.
Additional checks are added to fix the detection of the last memory region
in GetMemoryRegions or repeating the "memory region" command when the
target has non-address bits.
Normally you keep reading from address 0, looking up each region's end
address until you get LLDB_INVALID_ADDR as the region end address.
(0xffffffffffffffff)
This is what the remote will return once you go beyond the last mapped region:
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
[0x0001000000000000-0xffffffffffffffff) ---
Problem is that when we "fix" the lookup address, we remove some bits
from it. On an AArch64 system we have 48 bit virtual addresses, so when
we fix the end address of the [stack] region the result is 0.
So we loop back to the start.
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
[0x0000000000000000-0x0000000000400000) ---
To fix this I added an additional check for the last range.
If the end address of the region is different once you apply
FixDataAddress, we are at the last region.
Since the end of the last region will be the last valid mappable
address, plus 1. That 1 will be removed by the ABI plugin.
The only side effect is that on systems with non-address bits, you
won't get that last catch all unmapped region from the max virtual
address up to 0xf...f.
[0x0000fffff8000000-0x0000fffffffdf000) ---
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
<ends here>
Though in some way this is more correct because that region is not
just unmapped, it's not mappable at all.
No extra testing is needed because this is already covered by
TestMemoryRegion.py, I simply forgot to run it on system that had
both top byte ignore and pointer authentication.
This change has been tested on a qemu VM with top byte ignore,
memory tagging and pointer authentication enabled.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D115508
|
|
Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.
After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.
|
|
|
