[lldb-dev] Interactive commands in LLDB

[jingham at apple.com]

I must be missing something.  This seems like the barest sugar on top of:

(lldb) expr m_myclass_sp
<regular expr output>
(lldb) <UP ARROW>->m_impl
<regular expr output>

etc.  I guess it keeps you from having to know which things are pointers and which are not, but you generally have to know that for you day job anyway.

What am I missing that makes it worth adding & then users having to learn a new command set to do something expr already does pretty well?

Jim

> On 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
> 
>