This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Add a way to get a scripted process implementation from the SBAPI
ClosedPublic

Authored by mib on Feb 2 2023, 5:31 PM.

Details

Summary

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.

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>

Diff Detail

Event Timeline

mib created this revision.Feb 2 2023, 5:31 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 2 2023, 5:31 PM
mib requested review of this revision.Feb 2 2023, 5:31 PM

This is an interesting idea.

I suppose I find it a little strange that something from the SB API is passing a void * back to the caller instead of something more well defined (like another SB class or some primitive) but I suppose that's not the worst thing in the world. I'm not sure how else you would get a C++ method to return a type that is dependent on which language the method was called from...

lldb/bindings/interface/SBProcess.i
347–348

Maybe a docstring is in order? Something to explain how to use this.

mib added a comment.Feb 2 2023, 5:40 PM

This is an interesting idea.

I suppose I find it a little strange that something from the SB API is passing a void * back to the caller instead of something more well defined (like another SB class or some primitive) but I suppose that's not the worst thing in the world. I'm not sure how else you would get a C++ method to return a type that is dependent on which language the method was called from...

So, technically, we could also do something similar with SBStructuredData since now they don't allow holding generic objects. You can then image that the user will be able to unwrap the structured data to get the original object. I think @jingham also had other examples in mind, like for breakpoint python commands, if I'm not mistaken.

mib updated this revision to Diff 494485.Feb 2 2023, 5:54 PM
mib marked an inline comment as done.

Add docstring.

jingham requested changes to this revision.Feb 3 2023, 10:23 AM
jingham added inline comments.
lldb/bindings/python/python-typemaps.swig
57

Won't this make every out void * claim to be a Python Object in the SWIG-ed output? That seems dangerous. Maybe you should make a typedef "LLDBScriptObjectPointer" or whatever, and that's what the SB API returns. Then you could bind to that in the SWIG type map.

This revision now requires changes to proceed.Feb 3 2023, 10:23 AM
mib updated this revision to Diff 494695.Feb 3 2023, 11:19 AM

Address @jingham comment.

JDevlieghere accepted this revision.Feb 3 2023, 11:50 AM

I'd call it GetScriptedImplementation() to make it clear this isn't going to give you the underlying lldb_private class or anything like that.

What happens in Python when you don't have a scripted implementation? Is the result None? Let's add a test for that too.

Besides that this LGTM.

lldb/bindings/python/python-typemaps.swig
59–62
if (const void* impl = $1)
    $result = (PyObject*) impl;
jingham accepted this revision.Feb 3 2023, 12:13 PM

LGTM if Jonas is also happy.

This revision is now accepted and ready to land.Feb 3 2023, 12:13 PM
mib updated this revision to Diff 494704.Feb 3 2023, 12:27 PM
mib edited the summary of this revision. (Show Details)

Address @JDevlieghere feedback:

  • Rename API to GetScriptedImplementation
  • Add test for non scripted process plugins
mib marked 2 inline comments as done.Feb 3 2023, 12:28 PM
This revision was landed with ongoing or failed builds.Feb 3 2023, 12:29 PM
This revision was automatically updated to reflect the committed changes.