Milen, As far as "native plugin languages" go, Python is the language we use to implement higher-level features (like test-suites) on top of LLDB. Our plug-ins, which are (as you say) written in C++, typically provide LLDB with specific implementations of functionality, like object-file reading, or process control, that varies from platform to platform. At first glance, your feature would not appear to be a "plug-in" in that sense.
LLDB has full type information, and LLDB's expression parser can get the values of variables that are available in the current scope. LLDB (like GDB) gets the information about what variables are in scope at a particular point from the debug information provided with the program (on OS X, the DWARF debugging information). This information does not come with full ASTs, only with a mapping from assembly locations to source lines. What you will need to implement, if you want to find conditionals, is a mechanism that discovers conditionals in the source code of a function, and then maps them back using the debugging information to assembly locations. Then, wherever you're stopped, you can see what conditions are true at the current point, and make your symbolic deductions. Discovering conditionals involves parsing, which LLVM can do for you. I would be wary of implementing source-code parsing as a general feature of LLDB, because it's difficult to determine the exact context in which a source file was compiled – i.e., the #defines that were set, etc. It sounds like a good first step might be to sketch out the algorithm you intend to use for finding what conditions hold at the current execution point, and then seeing what parts require new API functionality. Sean On Oct 18, 2010, at 10:59 AM, Milen Dzhumerov wrote: > Sean, > > On 18 Oct 2010, at 18:35, Sean Callanan <[email protected]> wrote: > >> Milen, >> >> it sounds like what you're proposing could be done with Python code. > > I'd personally prefer doing it in C++ (lldb's native plugin language as far > as I know). I assume that shouldn't be a problem. > >> One thing you'd have to be careful about is figuring out where the >> conditionals are and what they are testing. Are you going to pre-parse the >> code before it comes into LLDB? We don't have an infrastructure for getting >> ASTs at the moment. > > What kind of representation / information does lldb currently have? Ideally, > the AST would be the most useful. One unknown (to me) would be how the > mapping between variable names and compiled code would be accomplished (I > assume that lldb doesn't have access to llvm IR of the running program) - in > any case, I assume the mapping should be a relatively trivial engineering > problem. Any thoughts on that? > >> >> If you implement this on top of LLDB using the external API, I think that >> will allow you to get as many results as possible without needing to go in >> and implement internal features. Then, later, once you're confident about >> what information needs to be associated with what data structures, we can >> discuss adding that as a general infrastructure that anyone can use. > > I think this sounds as the approach to take. I'm very interested into adding > range information histories so that analysis tools can be built on top. > > Milen >> _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
