Sean, On 18 Oct 2010, at 19:15, Sean Callanan <[email protected]> wrote:
> 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. I see. In this case, the only "plug-in" parts would be any bits that need to expose additional information in order to implement the symbolic queries. > 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. So, from what I can tell, the general algorithm would need to: 1) find conditionals using the LLVM parser (I don't know if DWARF contains references to source code) 2) The debugging information can now map variables to registers etc Regarding determining which conditional paths were taken whenever we are stopped - would injecting code after the branch points which will add outcome data to a data structure for the current stack frame (I'm making a lot of assumptions here) work? I know that gdb implements breakpoints this way, I think (code injection + trapping). As an example, after if(a < b) and the programming wanting to track a, we would pull the value of b from the appropriate register, record that information and continue execution. > 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. Would the algorithm above work or does this not fall within the LLVM architecture? I'm very interested in the project, so I will have a final discussion with my mentor tomorrow. My proposal would most likely include symbolic range queries and optionally a metadata framework so that we can accumulate data during runtime. In the future, range information + history of the ranges for variables could be used to develop some more advanced functionalities within lldb. Any thoughts on that? Milen _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
