[lldb-dev] Interactive commands in LLDB
Zachary Turner
zturner at google.com
Wed Feb 25 18:30:50 PST 2015
I know you answered this briefly on IRC, but i had to run so I didn't have
time to ask for clarification. What is the benefit of this approach over a
stateful command similar to git bisect? I know you said something about
exploring very large types, but I didn't quite follow why this approach
lends itself better.
There are a number of advantages of the stateful approach. One is that you
can run arbitrary commands between stages of the traversal. Maybe you see a
pointer whose value is a module load address , and you want to dump info
about the module loaded at that address.
It also provides more flexibility even in the exploration process. If a
field is a void* for example, an interactive command might be forced to
give up, whereas a stateful non interactive command may be able to be
forced into treating it as a specific type through a cast expression. It
seems like the number of times you would know more than the type
information lets on might warrant the additional flexibility.
It might also be difficult to test an interactive command. Would the
command callback into python? Seems difficult.
Anyways, these are just ideas. I do like the general idea of a command that
explores type hierarchies this way
On Wed, Feb 25, 2015 at 6:11 PM Siva Chandra <sivachandra at google.com> wrote:
> Hello,
>
> This is more like a question through a proposal on how to add
> interactive commands to LLDB.
>
> By an interactive command, I mean that when one runs the command, it
> asks for more input from the user. AFAICT, there is no way currently
> to do that in LLDB. There is an IOHandlerConfirm which can be used to
> get a yes/no response from the user, but what I am looking for is
> something which can read in "richer" inputs. Could we extend
> IOHandlerConfirm as follows:
>
> 1. Rename IOHandlerConfirm to IOHandlerUserResponse
> 2. To support the existing use case of "confirm", add two methods,
> UserResponseIsYes and UserResponseIsNo to it.
> 3. Make its GetResponse method return the raw user input.
> 4. Add few convenience methods to it like GetResponseAsUint8,
> GetResponseAsString etc.
>
> The above is a big picture idea; there could be a few details to
> resolve when getting down to implementation. My motivation to require
> a facility like this is to implement something like the "explore"
> command of GDB:
> https://sourceware.org/gdb/current/onlinedocs/gdb/Data.html.
>
> Thanks,
> Siva Chandra
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150226/2587cdbc/attachment.html>
More information about the lldb-dev
mailing list