[lldb-dev] Interactive commands in LLDB

[Zachary Turner]

The nice thing about this approach is that the different subcommands of
explore can take command line options, giving much more flexibility over
the exploration process.  For example, consider replacing "explore status"
at the 4th step of my example with "explore status -v" (i.e. verbose)

(lldb) explore status -v
m_foo_sp
+ m_impl           +0x0   <Foo*>
    + member1            +0x0   <const char*>   "String value
    + member2            +0x4   <int>                10
    + (Baz*)member3   +0x8   <Baz*>
        + m_baz1               +0x0     <double>     3.5
+ m_ref_count   +0x4    <int>       4

You can't get this kind of flexibility, or the ability to run arbitrary
commands like the "target modules lookup" with a question / answer session.

On Thu, Feb 26, 2015 at 9:58 AM Zachary Turner <zturner at google.com> wrote:

> Implementing the explore command as a stateful command in the way I had
> envisioned it would be a bit different than the process attach example
> here, so it's not the best point of comparison.  What I imagined a session
> would go like is something like this:
>
> (lldb) explore begin m_myclass_sp
> <std::shared_ptr<MyClass>> m_foo_sp
> + m_impl           +0x0   <Foo*>
> + m_ref_count   +0x4    <int>       4
>
> (lldb) explore follow m_impl
> <MyClass*> m_foo_sp->m_impl
> + member1        +0x0   <const char*>   "String value
> + member2        +0x4   <int>                10
> + member3        +0x8   <Bar*>
>
> (lldb) explore follow (Baz*)member_3
> <Baz*>  (Baz *)m_foo_sp->m_impl->member3
> + m_baz1         +0x0     <double>     3.5
>
> (lldb) explore status
> <Baz*>  (Baz *)(m_foo_sp->m_impl->member3)
> + m_baz1         +0x0     <double>     3.5
>
> (lldb) explore up
> <MyClass*> m_foo_sp->m_impl
> + member1        +0x0   <const char*>   "String value
> + module_addr   +0x4   <lldb::addr_t>    0x80f23490
> + member3        +0x8   <Bar*>
>
> (lldb) target modules lookup -a 0x80f23490
> // Information about the module loaded at 0x80f23490 is dumped
>
> (lldb) explore stop
> (lldb)
>
> On Thu, Feb 26, 2015 at 9:46 AM <jingham at apple.com> wrote:
>
>>
>> > On Feb 26, 2015, at 6:57 AM, Siva Chandra <sivachandra at google.com>
>> wrote:
>> >
>> > On Wed, Feb 25, 2015 at 6:36 PM,  <jingham at apple.com> wrote:
>> >> I haven't used the gdb "explore".  It does seem a little odd to me,
>> >> like something that is well modeled by a turn-down GUI variable
>> >> display but not so much by this kind of question & answer session.
>> >> But I haven't used it so I can't say.
>> >
>> > My own point of view: I have hardly ever used an IDE or GUI for dev
>> > work or debugging. Having a CLI for this would likely be of value to
>> > people like me. However, I do agree that if one is using a GUI, this
>> > should not be required. But would that GUI require to understand the
>> > current source language? For example, it should be able to do produce
>> > syntax for field access like a.b->c.d. May be its not an issue.
>>
>> It is driven by the SBValue system, it's up to that system to produce the
>> notion of "child objects", then the GUI just reflects that.  The SBValue
>> system clearly has to understand the source language.  You can even ask it
>> "give me the expression that produced this child in the current source
>> language, for instance if you then want to pass that value to an expression
>> for some purpose.  But for basic data display the SBValue layout works fine.
>>
>> >
>> >> OTOH, I do have other uses for a slightly more advanced interactive
>> >> IO handler.  For instance, it you do "process attach -n" and there are
>> >> multiple processes with the same name, we show you a nice little
>> >> listing of the processes and their arguments so you can figure out
>> >> which PID you actually want to attach to.  But it would be nicer to say
>> >> "here are these five processes, type the index of the one you want to
>> >> attach to."
>> >
>> > One could argue that this case can also be handled by a GUI more
>> > effectively? :-)
>>
>> I wouldn't.
>>
>> >
>> >> Maybe you could also have "show me more about process 3" which
>> >> could dump a more verbose output, and then you would decide to
>> >> attach to 3...
>> >
>> > So, do you envision this to happen in a single command "session", or
>> > do you envision something like what Zach talked about: a command
>> > retaining state across sessions. I am not a fan of keeping state
>> > across sessions as managing state between two sessions could get
>> > tricky and IMO not worth it for the command I have in mind.
>>
>>
>> Again, I haven't thought about the best way to implement something like
>> the "explore" command.  So I don't have an opinion about how to implement
>> it.
>>
>> In the simple "pick from a list" version of selecting a process, it would
>> also be a one-shot thing so statefulness isn't really relevant.  But if you
>> imagine doing something like:
>>
>> (lldb) process attach -n Foo
>> INDEX  PID ARGUMENTS
>> 1      111  foo bar
>> 2      222  foo bar bar
>> Select a index to attach to (?<N> for more info) > ?1
>> <More info on process 1>
>> Select a index to attach to (?<N> for more info) > ?2
>> <More info on process 2>
>> Select a index to attach to (?<N> for more info) > 2
>> Attaching to PID 222
>> (lldb)
>>
>> Then making it a complete session is much more natural than having to
>> come in & out of "process attach".
>>
>> Jim
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150226/968fd76a/attachment.html>