Yes, ideally there would be some language runtime manager which the plugins would register with, and generic code would call it to dispatch general runtime tasks to all the specific runtimes. ModulesDidLoad would be an good first candidate for this.
The story is complicated by the fact that there are runtime specific things that you want to do before you know that the runtime for that language has actually been loaded into your program or not (so you may not know which specific instance of the runtime is available.) It used to be the case that Apple supported the gcc3 & gcc4 C++ runtimes (they had different mangling schemes and everything) so you could have a vanilla ObjC program that could load a framework that used either one or both of these runtimes. You couldn't necessarily know a priori which one you will encounter, so the runtimes had to come into being during the life of the process, not the target. However, there are clearly some LanguageRuntime jobs you would like to get done without having a particular runtime. So for instance setting the exception breakpoints is complicated because you want to set the breakpoint when you just have a target, but you don't know what actual resolver to use till the language! runtime for that language actually shows up. And in another instance, the LanguageRuntimeManager's ModulesDidLoad call would normally call each loaded language runtime's DidLoad, but if it a particular LanguageRuntime wasn't loaded yet it would have to call a static "Does this module load indicate that runtime for this language exist/if so create same" method. It will probably be necessary to have a LanguageRuntimeTarget in the target which handles all the things you might set up for the language before a specific instance of that runtime shows up, and then the one in the process that corresponds to the actual version of the runtime we've discovered during the course of running. More generally, there are some places where you will obviously have to talk directly to specific runtimes - for instance the ClangExpressionParser & friends are very C/C++/ObjC specific and ask fairly detailed questions of the runtime. I'm not sure that it's ever going to be easy to push all that into generic interfaces. In other places we could make a general interface and have the runtime manager do the specific runtime iteration. When we started drafting out lldb, I didn't feel like I knew enough about the way the LanguageRuntimes would work to want to try to generalize the interfaces, so I didn't make the manager class, etc, but left calling into the runtimes fairly ad hoc. The process of supporting a couple more languages will make this clearer and give us the insight to do this piece of work correctly. Jim > On Apr 15, 2015, at 12:29 PM, Colin Riley <[email protected]> wrote: > > In http://reviews.llvm.org/D9002#156564, @clayborg wrote: > >> So the main question here is what are you trying to accomplish by adding >> this call? Your LanguageRuntime plug-in will have a static CreateInstance() >> and that looks at the target and looks at the image list of that target to >> see if a shared library is around for the. See the function named >> "AppleObjCRuntime::GetObjCVersion()" in AppleObjCRuntime.cpp for an example. >> AppleObjCRuntimeV1::CreateInstance() and >> AppleObjCRuntimeV2::CreateInstance() call this function to check the targets >> image list to look for anyone that has certain things in any of the images. >> >> Currently, you call a function in lldb_private::Process to get your language >> runtime: >> >> virtual ObjCLanguageRuntime * >> GetObjCLanguageRuntime (bool retry_if_null = true); >> >> >> You would add one of these for RenderScript and it would to to call >> "LanguageRuntime *RenderScriptLanguageRuntime::CreateInstance(Process >> *process, lldb::LanguageType language)" in order to try and instantiate your >> runtime. You would then look through the shared libraries to see if your >> render script shared library is loaded and return a valid instance if it is >> there, and NULL if not. > > > The issue here is that I'd need to add some sort of RenderScript base > language definition to the Target project, just like ObjC. I dont think this > is ideal; as more languages are added to LLDB, they should really remain in > their own plugin project. It pollutes the Target with language and higher-end > specifics which (in my opinion, of course!) ought not to be there. If you > look in Target::ModulesDidLoad, it calls into the ObjC runtime to check there > for the runtime library (using that Process helper function). I'd envisaged > as a first step adding something like the following to that function, under > the ObjC logic: > > LanguageRuntime* rs_runtime = > process->GetLanguageRuntime(eLanguageTypeExtRenderScript); > if (rs_runtime) > rs_runtime->ModulesDidLoad(module_list); > >> Let me know what you were thinking you want >> LanguageRuntime::ModulesDidLoad(...) for. The only reason to add it would be >> so that you existing language runtime could be kept up to date and know >> about all shared libraries that the language runtime might want to know >> about, but I doubt you need that functionality and I would venture to say we >> don't need this function. > > > This is actually one use case. RenderScript runs alongside other programming > languages, such as C++ or Java. In RenderScript, its kernel objects can be > loaded at runtime dynamically and ideally i'd like these tracked as early as > possible. I guess there could be another hook into modifications in the > module list which Language Runtimes could use, either way I do require that > functionality. > > Additionally, this is also a step in the direction of multiple languages > being debugged at once in a single process which is not C++/ObjC, and whilst > it's a small step I do think there needs to be more ways for other languages > to be supported without adding direct support into the various core modules > of LLDB. > > If you think there is a better way of achieving this, I'm of course open to > having that discussion! > > > 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
