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 <[email protected]> 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/
>
>
_______________________________________________
lldb-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
