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

[Med Ismail Bennani via lldb-commits]

medismailben wrote:

> Is part of the goal of this class to extend another platform by being able to override a built in platform? If so, we might want the script platform class to be able to specify the name of the platform it wants to extend with a method. Something like:
> 
> ```
> class ScriptedPlatform:
>   def extends_platform_name(self):
>     '''Get the name of the internal platform this class extends.'''
>     return "iPhoneOS.platform"
>   def get_platform_name(self):
>     '''Get the name of this platform.'''
>     return "iPhoneOS.platform.scripted"
> ```
> 
> Then the script platform python class would instantiate a `"iPhoneOS.platform"` platform and keep it as an instance variable, then the ScriptedPlatformPython would check if the python class implements the method in python, and if it doesn't, it will call through to the `"iPhoneOS.platform"` platform via its instnace variable. Any methods that are overridden in the scripted pyton class would take precedence and not call through to the underlying platform. If a python class doesn't have a `def extends_platform_name(self):` method, then any methods that aren't there just return an error of `"unimplemented"`.

Very interesting idea. This is not was I was thinking of while implementing this: `ScriptedPlatform` is meant mostly to mock a new platform to be able to list and "launch" or "attach" to processes (mainly `ScriptedProcess` but nothing should prevent us to launch a `GDBRemote` process or any other kind.

I think this is a pretty cool idea, but this PR is already pretty big & intrusive, so I think we should do it as a follow-up, once we've figured out how we could break up platforms like @JDevlieghere explained.

I'd also love to hear other people opinion on extending platforms through ScriptedPlatform (cc @labath @jimingham @JDevlieghere )

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