[Lldb-commits] [PATCH] Add ModulesDidLoad to LanguageRuntime

[Greg Clayton]

Thanks for explaining what your thoughts are. Sounds like we should add a new top level command like "language" whose for is "language <language-name> ...".

So we could do:

(lldb) language renderscript ...

This command would take the second parameter "renderscript" and lookup the enumeration eLanguageRenderscript and then ask the process for the language runtime:

Language language;
if (language.SetLanguageFromCString(arg2))
{
    LanguageRuntime *language_runtime = process->GetLanguageRuntime(language.GetLanguage());
    if (language_runtime)
    {
        Error error = language_runtime->HandleCommand(remaining_args);
        ....
    }
}

Then each language runtime can vend its own commands for inspection and anything else you want to do.

We also will need a special language runtime breakpoint that we can set that uses a LanguageRuntime to implement special breakpoints with their own set of unique options to allow for complex language runtime breakpoints as you specified below...

How does that sound?

> On Apr 21, 2015, at 9:56 AM, Colin Riley <colin at codeplay.com> wrote:
> 
> There is a variety of things that a language runtime can expose. Scripting languages can expose versions and various other things such as jit/interpeter status and object statuses. RenderScript offers details on object allocations, device capabilities and workload flow. Breakpoints on certain actions could be accomplished, too.
> 
> Here is an example renderscript workflow:
> 
> 1. Connect to target which is running a process with many different languages, say C++ and RenderScript.
> 2. User stops in C++ code.
> 3. User knows the program contains renderscript, loads the RenderScript Language Runtime, which scans the process and produces a model of the environment.
> 4. Using new lldb commands from the language runtime, can inspect the state of the RenderScript runtime, and sees a function kernel loaded it wants to inspect.
> 5. User sets breakpoint on this renderscript runtime kernel function or on some other exception event.
> 6. Process stops at breakpoint in renderscript code, user requests information on a parameter.
> 7. RenderScriptRuntime uses information from process and inspected runtime state to get the allocation details and kernel usage as well as standard 'lldb value'
> 8. User does something else..
> 
> Maybe LanguageRuntime isn't the best place for this - but is there somewhere else where this makes sense? When I read language runtime, I thought it was anything to do with a language at 'run-time', so if a language actually has a runtime/manager library, interactions with it would occur there. The ability to have lldb collect details and create a model of the environment helps, especially in the cases of scripting languages with relevant C++ bindings.
> 
> 
> REPOSITORY
>  rL LLVM
> 
> http://reviews.llvm.org/D9002
> 
> EMAIL PREFERENCES
>  http://reviews.llvm.org/settings/panel/emailpreferences/
> 
>