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 <ztur...@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 <jing...@apple.com> wrote: > > > On Feb 26, 2015, at 6:57 AM, Siva Chandra <sivachan...@google.com> wrote: > > > > On Wed, Feb 25, 2015 at 6:36 PM, <jing...@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 > > _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
