[lldb-dev] Interactive commands in LLDB

[Zachary Turner]

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/cf83b892/attachment.html>