[Lldb-commits] [lldb] [lldb/Plugins] Introduce Scripted Platform Plugin (PR #99814)

[via lldb-commits]

jimingham wrote:

> > I'd also love to hear other people opinion on extending platforms through ScriptedPlatform (cc @labath @jimingham @JDevlieghere )
> 
> I think that having the ability to forward operations to existing platform instances would be very useful. If you look at PlatformQemuUser, most of its functions just forward operations to be host platform. We also have another downstream plugin which looks very similar to that. I would love if both of these could be lightweight python wrappers.
> 
> That said, I'm not exactly sure how Greg's idea would work, or if it's even needed. Some of this functionality without any special support, by just having an `SBPlatform` member inside the python class. This would be more flexible as you could call it only when it suits you (going with the Qemu example, the emulator mostly exposes the host filesystem, but it has some special remapping logic for system libraries (like LD_LIBRARY_PATH, but implemented in the emulator), so we may want to implement get/putfile mostly by deferring to the host, and only doing something custom for special paths). And if you really wanted to you could make a python wrapper class that makes all of this looks like (python) inheritance -- without any special support in lldb.
> 
> The main flaw in this idea is that the SBPlatform interface is pretty small compared to the internal Platform interface. I'm guessing the python class will be implementing something like the internal interface, while it will only have the external API to work with...

For Greg's idea to be useful, you mostly don't want to override the platform you are extending, you want to do some stuff before the underlying platform call, then you want to do the platform call, then you potentially want to do some more work afterwards.  So it would have to be something more like:

```
class ScriptedPlatform:
  def extends_platform_name(self):
    '''Get the name of the internal platform this class extends.'''
    return "iPhoneOS.platform"
  def extend_before_attach_to_process(self, attach_info):
     '''Do something to prepare for the attach"
  def extend_after_attach_to_process(self, process):
     '''Do something after the platform attach was complete'''

```
And maybe:

```
  def override_list_processes():
  '''Take over the listing of processes from the underlying Platform'''

```
But particularly for the before & after wrapping, that seems like it would be awkward to read and write, since you have to partition the before & after into different methods.

We should look at what methods the scripted platform has/will have.  For the most part the ones there now look like things that it would be quite reasonable to ask the SBPlatform to do through the API.  If that is true, then I think allowing the scripted platform to make an instance of the SBPlatform it wants to extend and just dispatch to that directly in Python would be a more straightforward design.

https://github.com/llvm/llvm-project/pull/99814