You'll still need HandleCommand for pass through commands. lldb commands send to lldb-mi are handled normally, so something like "file a.out" would set up a target using a.out. "-interpreter exec console <cmd>" does the same thing. Other than that, I'm all for cleaning up lldb-mi. There were some funky decisions made when it was first developed.
Ted -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > -----Original Message----- > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jim > Ingham via lldb-dev > Sent: Tuesday, April 24, 2018 5:19 PM > To: Greg Clayton <clayb...@gmail.com> > Cc: LLDB <lldb-dev@lists.llvm.org> > Subject: Re: [lldb-dev] Welcome Alexander! > > > > > On Apr 24, 2018, at 3:08 PM, Greg Clayton <clayb...@gmail.com> wrote: > > > > > > > >> On Apr 24, 2018, at 3:00 PM, Jim Ingham <jing...@apple.com> wrote: > >> > >> > >> > >>> On Apr 24, 2018, at 2:46 PM, Greg Clayton <clayb...@gmail.com> wrote: > >>> > >>> > >>> > >>>> On Apr 24, 2018, at 2:35 PM, Jim Ingham <jing...@apple.com> wrote: > >>>> > >>>> > >>>> > >>>>> On Apr 24, 2018, at 9:44 AM, Greg Clayton <clayb...@gmail.com> > wrote: > >>>>> > >>>>> > >>>>> > >>>>>> On Apr 24, 2018, at 9:37 AM, Jim Ingham <jing...@apple.com> > wrote: > >>>>>> > >>>>>>> > >>>>>>> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev <lldb- > d...@lists.llvm.org> wrote: > >>>>>>> > >>>>>>> Welcome Alexander! > >>>>>> > >>>>>> Yes, welcome! > >>>>>> > >>>>>>> > >>>>>>> The title might be more stated as "Reimplement lldb-mi to correctly > use the SB API instead of using HandleCommand and regular expressions to > parse the command results" as it is already using the SB API, just not using > it > anywhere close to correctly! > >>>>>>> > >>>>>>> I look forward to seeing the changes. > >>>>>>> > >>>>>>> A few things I ran into when playing with lldb-mi: > >>>>>>> - file-exec or exec-file packet might come _after_ some breakpoints > are set. We should make sure we create a lldb::SBTarget right away and set the > breakpoints on the empty target so that we don't miss these breakpoints if > this > is still an issue. Then the when we receive the exec-file packet, we set the > file > on the target > >>>>>> > >>>>>> Breakpoints set before any target is created are set on the dummy > target. Breakpoints on the dummy target are copied into any new targets. So > this should not be necessary. If that wasn't working we should figure that > out, > but it's not the responsibility of the MI to get this right. > >>>>> > >>>>> We are trying not to use the command line and the command line is > what uses the dummy target automatically. When using the SB API you use a > lldb::SBTarget to set the breakpoint on so you need a target. What do you > suggest we use for the target? I would rather the lldb-mi code not rely on the > currently selected target or the dummy target. > >>>> > >>>> lldb-MI models gdb's behavior, which is one debugger with one target. > There is no command to add or switch to targets, etc. So it doesn't seem > unreasonable for MI to keep track of its one actual target and if that is > empty, > use SBDebugger::GetDummyTarget. The other option is to make a blank target > up front and then add files to it when you see the -file-exec command. But > that > seems more error-prone than using the mechanism lldb provides for doing > things before you have a target. Again, if we were modeling an API that could > switch targets we might want to do something more clever. But that isn't how > the GDB-MI was set up to work. > >>>> > >>> > >>> lldb-mi code may or may not have a target when it needs one. If it doesn't > have a target, use the SB API to get the dummy target and use that. > >>> > >>> Jim: is the dummy target good for anything other than adding breakpoints > to? What all gets copied from a the dummy target to the new target when one > gets created? > >> > >> At present it only does breakpoints and stop hooks (see > Target::PrimeFromDummyTarget.) I didn't do watchpoints since those are > seldom things you want to set generically, but you could probably add that. > Was there anything else you were thinking of? > >> > > > > No, just mostly trying to let Alexander know what he should use the Dummy > target for and also for my own knowledge. If there are MI clients that do > other > things, we will need to know if we need to create an empty real target if they > aren't breakpoints or stop hooks. > > I can't think of any other things you add to a target like this. The > settings get > inherited, and once you've started adding modules, I think you should create a > new target to hold them. But for anything interesting that's missing, as > long as > they are copiable it would be easy to add them. Just call > GetSelectedOrDummyTarget when you go to set them, and then put the copy in > PrimeFromDummyTarget. > > > > > Greg > > > >> Jim > >> > >>> > >>> Alexander, feel free to ask questions if you didn't understand any of the > above information. > >>> > >>> > >>> > >>>> Jim > >>>> > >>>> > >>>>> > >>>>>> > >>>>>>> - remove all uses of HandleCommand and use SB APIs where possible > >>>>>>> - Add any SB API that might be missing and require us to use > HandleCommand > >>>>>>> > >>>>>> > >>>>>> The rest of these seem good guidelines. > >>>>>> > >>>>>> Jim > >>>>>> > >>>>>> > >>>>>>> Good luck and let us know if you have any questions, > >>>>>>> > >>>>>>> Greg Clayton > >>>>>>> > >>>>>>> > >>>>>>>> On Apr 23, 2018, at 3:19 PM, Adrian Prantl via lldb-dev <lldb- > d...@lists.llvm.org> wrote: > >>>>>>>> > >>>>>>>> Please join me in welcoming Alexander Polyakov, who will be > working on cleaning up and completing LLDB's lldb-mi fronted as part of his > Google Summer Of Code project: > >>>>>>>> > >>>>>>>> Reimplement lldb-mi on top of the LLDB public SB API > >>>>>>>> > https://summerofcode.withgoogle.com/projects/#5427847301169152 > >>>>>>>> > >>>>>>>> -- adrian > >>>>>>>> _______________________________________________ > >>>>>>>> lldb-dev mailing list > >>>>>>>> lldb-dev@lists.llvm.org > >>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> lldb-dev mailing list > >>>>>>> lldb-dev@lists.llvm.org > >>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev