jingham added a comment. I have a couple of structural questions.
First, it would be good to stop a bit and think about how to make the StackFrameRecognizer's return data more flexible. At some point, for instance, it would be great to be able to add a StackFrameRecognizerPython and then let people add their own plugins to handle special data from functions they know about in their code. Basically DataFormatters for functions on the stack. But if the way you get data out of a Recognizer is to call specific functions on the recognizer, then you're going to have to enumerate up front all the kinds of data a recognizer can provide, which will make this harder. It seems however like providing some interesting ValueObjects is a pretty common thing to do, so maybe it would be better to have an API like: ValueObjectSP GetValueObjectOfKind(const char *kind); in which case you probably also want: GetSupportedKinds() that returns some kind of string list so you could anonymously print all the interesting information. I actually like having a command to get the current exception (and it's backtrace) for a thread. We do an analogous thing when listing the queue that launched the current thread (and the backtrace when dispatched) with: thread backtrace -e true So now we have two very different ways to do analogous things. Maybe it would be better to change --extended to take an enum, and then do: thread backtrace --extended queues or thread backtrace --extended exception https://reviews.llvm.org/D43886 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
