[lldb-dev] Symbolic Queries + LLDB

Greg Clayton gclayton at apple.com
Mon Oct 18 10:46:04 PDT 2010


We currently do link against much of clang and llvm, so it wouldn't be out of the question to be able to compile an AST inside the LLDB walls and do the analysis in house. The main issue we have with the clang and llvm stuff is that there is no exportable API. LLDB on the other hand does try and provide a public API, so it might be best to do some of this inside LLDB and only expose what clients would need.

Milen, 

Have you thought about what API you would want for this?


On Oct 18, 2010, at 10:35 AM, Sean Callanan wrote:

> Milen,
> 
> it sounds like what you're proposing could be done with Python code.  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.
> 
> 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.
> 
> Sean
> 
> On Oct 18, 2010, at 10:29 AM, Milen Dzhumerov wrote:
> 
>> Sean,
>> 
>> On 18 Oct 2010, at 18:00, Sean Callanan <scallanan at apple.com> wrote:
>> 
>>> Milen,
>>> 
>>> when you say "the range of values it can take," are you referring to adding a kind of watchpoint that records range information, so that you can perform integer range analysis etc?  Or are you referring to a query that operates on all instances of a variable (say, a class member) existent at the current time?  Given what KLEE does, I assume the former.
>> 
>> Yes, I was referring to the former. As an example, the programmer would turn on range tracking for a particular variable. Let's assume execution has gone down the path if(x < 5) and the debugger stopped at a breakpoint along that execution. The programmer can then ask what the possible values of x are and it will say [int_min, 5). 
>> 
>> I would assume that's relatively easy to do - is there anything in particular I should be aware of? 
>> 
>>> Right now, even before you start looking at the query infrastructure – or even the watchpoints, really – LLDB really needs support for keeping time-stamped metadata about variables and user interactions.  Because LLDB uses editline, it gets some level of command-line history, but that's pretty much it right now.  A proper metadata infrastructure could provide full history for variable values and function executions, providing a foundation for a variety of LLDB-based program analysis tools.
>> 
>> That sounds quite interesting. I'll be happy to implement the metadata infrastructure, time permitting. Another question - doing the range analysis does not depend on the aforementioned metadata subsystem, as far as I understand? 
>> 
>>> Adding this kind of metadata support to LLDB would be a sizable piece of work, but it could allow you to bring over versions of some KLEE-based tests.  What do you think?
>> 
>> Sounds appealing to me. As the project would need to make measurable progress, ideally it should be possible to do the range analysis / symbolic queries as a starting point and optionally go a lot further.
>> 
>> Milen
>>> 
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev





More information about the lldb-dev mailing list