| 680ca7f2 | 04-Mar-2022 |
Med Ismail Bennani <[email protected]> |
[lldb/Plugins] Add ability to load modules to Scripted Processes
This patch introduces a new way to load modules programatically with Scripted Processes. To do so, the scripted process blueprint hol
[lldb/Plugins] Add ability to load modules to Scripted Processes
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 <[email protected]>
show more ...
|
| 45148bfe | 18-Jan-2022 |
Med Ismail Bennani <[email protected]> |
[lldb/Plugins] Fix ScriptedThread IndexID reporting
When listing all the Scripted Threads of a ScriptedProcess, we can see that all have the thread index set to 1. This is caused by the lldb_private
[lldb/Plugins] Fix ScriptedThread IndexID reporting
When listing all the Scripted Threads of a ScriptedProcess, we can see that all have the thread index set to 1. This is caused by the lldb_private::Thread constructor, which sets the m_index_id member using the provided thread id `tid`.
Because the call to the super constructor is done before instantiating the `ScriptedThreadInterface`, lldb can't fetch the thread id from the script instance, so it uses `LLDB_INVALID_THREAD_ID` instead.
To mitigate this, this patch takes advantage of the `ScriptedThread::Create` fallible constructor idiom to defer calling the `ScriptedThread` constructor (and the `Thread` super constructor with it), until we can fetch a valid thread id `tid` from the `ScriptedThreadInterface`.
rdar://87432065
Differential Revision: https://reviews.llvm.org/D117076
Signed-off-by: Med Ismail Bennani <[email protected]>
show more ...
|
| a758c9f7 | 08-Oct-2021 |
Med Ismail Bennani <[email protected]> |
[lldb/Plugins] Add memory region support in ScriptedProcess
This patch adds support for memory regions in Scripted Processes. This is necessary to read the stack memory region in order to reconstruc
[lldb/Plugins] Add memory region support in ScriptedProcess
This patch adds support for memory regions in Scripted Processes. This is necessary to read the stack memory region in order to reconstruct each stackframe of the program.
In order to do so, this patch makes some changes to the SBAPI, namely: - Add a new constructor for `SBMemoryRegionInfo` that takes arguments such as the memory region name, address range, permissions ... This is used when reading memory at some address to compute the offset in the binary blob provided by the user. - Add a `GetMemoryRegionContainingAddress` method to `SBMemoryRegionInfoList` to simplify the access to a specific memory region.
With these changes, lldb is now able to unwind the stack and reconstruct each frame. On top of that, reloading the target module at offset 0 allows lldb to symbolicate the `ScriptedProcess` using debug info, similarly to an ordinary Process.
To test this, I wrote a simple program with multiple function calls, ran it in lldb, stopped at a leaf function and read the registers values and copied the stack memory into a binary file. These are then used in the python script.
Differential Revision: https://reviews.llvm.org/D108953
Signed-off-by: Med Ismail Bennani <[email protected]>
show more ...
|