[lldb-dev] [RFC} [Patch] SBFunction::ExecuteFunction

[jingham at apple.com]

So one thing that you will have to work out here is that Symbols aren't specific to Targets, but ClangFunctions are.  The was lldb works, if two targets load the same shared library, only one lldb_private::Module is made, and added to the "global shared module cache" and then both Targets use the Symbols, Functions, etc that come from that module.  So you can't put a ClangFunction into a Symbol directly, or different Targets will fight over that resource.  It has to live in the Target somehow.

Also, you shouldn't access ObjC specific info directly from the Target, that functionality belongs in the ObjCLanguageRuntime plugin.  That way we can track changes in this if/when runtime behaviors change.  It already keeps a map <Class,Selector> -> Implementation so maybe you can hook into that to do what you want.  You can get the ObjC Language Runtime from the process.

Jim


> On Sep 23, 2014, at 1:02 AM, Carlo Kok <ck at remobjects.com> wrote:
> 
> On Sat, 20 Sep 2014 00:16:12 +0200, Greg Clayton <gclayton at apple.com> wrote:
> 
>> I just spoke with Jim Ingham and he change my mind. If, every time you stop, you want to call a function, this feature could come in handy.
>> 
>> Behind the curtains it should:
>> - install a ClangFunction down in the host and leave it there so it can be called (we do this internally with a few functions)
>> - allow it to be called with a SBValueList. All arguments will need to manually be supplied (the "this", and ObjC "cmd" and "selector" arguments, etc)
>> - it should be able to be uninstalled from the target
> 
> That gives a patch like the attached patch.
> 
> What I changed:
> * Target has a method to get & cache a selector
> * SBFunction has an ExecuteFunction api
> 
> +    lldb::SBValue ExecuteFunction(lldb::SBFrame &frame,
> +                                  lldb::SBValueList arguments,
> +                                  lldb::SBStream &errors,
> +                                  lldb::SBExpressionOptions options,
> +                                  bool reusable);
> 
> * SBTypeMemberFunction has an ExecuteFunction api:
> +    lldb::SBValue ExecuteFunction(lldb::SBFrame &frame,
> +                                  lldb::SBValue self,
> +                                  lldb::SBValueList arguments,
> +                                  lldb::SBStream &errors,
> +                                  lldb::SBExpressionOptions options,
> +                                  bool reusable);
> 
> Atm, it only supports ObjC methods and it prepares the selector for you, just requiring a "Self" valu and optional arguments, the reason I did this is because it's rather tricky to get a selector and wrap it in an SBValue from the calling side, and lldb itself allows for easier caching.
> 
> In ClangFunction I added GetCanonicalType() to the result & parameter types. This at least lets me use it with a selector like:
> 
> typedef int MyInteger;
> 
> +(MyInteger)MyFunction;
> 
> as it turns that into int instead of MyInteger. I'm still looking for a way to tell ClangFunction about the type aliases lldb knows about though (it's fully aware of MyInteger, it just fails on it when used from ClangFunction).
> 
> Feedback and ideas for the typedef issue appreciated.
> 
> -- 
> Carlo Kok
> RemObjects Software<lldb-execute-function-patch.patch>