> On Apr 24, 2018, at 5:24 PM, Александр Поляков <polyakov....@gmail.com> wrote: > > Thanks Jim, it helped me a lot. > > Can we do something like this: > 1) having empty dummy target;
Yes, you don't need to do anything here. The Debugger object always makes a dummy target. > 2) setting breakpoints to this dummy target until getting real file > through -file-exec-and-symbols; Right, the Debugger has an API: GetDummyTarget that will get this for you, and then you call GetDummyTarget().BreakpointCreate... > 3) creating new target and moving all breakpoints from dummy target to it; The move will happen automatically. > 4) clearing all breakpoints from the dummy target; This seems reasonable. Note however that you might inherit some breakpoints without seeing MI commands to do so - for instance from the user's .lldbinit file - and you probably want to propagate them every time you get a new -file-exec-and-symbols. So you should keep track of the breakpoints that were in the dummy target when you got started, and only delete the ones you made after that. > 5) back to 1); > Jim > > > > > > Regards, > Alexander Polyakov > > 2018-04-25 2:56 GMT+03:00 Jim Ingham <jing...@apple.com>: > In lldb, one Debugger can debug multiple different processes at a time. This > is one of the ways lldb differs from gdb (*)... In lldb, the Target is the > entity that represents a thing that you could debug. A Target might or might > not actually be debugging anything. If it is, the Target will have a > Process. You generally make a target by giving it a file and maybe an > architecture. Note the "file" command in lldb is just an alias for "target > create". It makes a target out of a file. Then when you want to debug that > file, you would say Target::Launch. > > But a Target need not have a file. For instance, if you do: > > $ lldb --pid 12345 > > lldb has to make an empty target, attach it to the process with pid 12345, > and only then will it actually know what the file is. > > Note also, in both lldb and gdb, you can set breakpoints in the > .lldbinit/.gdbinit file. But both these init files get read in BEFORE any of > the command line arguments (including the one with the file command) get > processed. > > So there has to be a way to hold onto breakpoints before any target is > created. This was simple in gdb since it only supports one target, so you > can just stuff the breakpoints into the global list of breakpoint you were > going to use. But you can't do that in lldb, because we could have many > targets. That's what the lldb "dummy target" is for. It holds onto > breakpoints that are made in the absence of any target, and then each time a > new target gets made, it gets seeded with breakpoints from the dummy target. > > Greg was worried that you could do: > > -break-set > -file-exec-and-symbols > > and he wanted to make sure that works. I think that's what you understood as > well. > > Since the gdb-mi interface models the way gdb works, it really only supports > having one target. So I was suggesting that the lldb-mi module keep track of > this one privileged Target, and to make sure that -break-set sets breakpoints > in the dummy target if that privileged Target is still empty. > > Jim > > (*) one lldb process can also support multiple Debuggers, but that's another > story... > > Jim > > > > > On Apr 24, 2018, at 4:41 PM, Александр Поляков <polyakov....@gmail.com> > > wrote: > > > > I don't completely understand how it possible to add breakpoint before > > choosing a file(did you mean -file-exec-and-symbols cmd?). > > And another important thing: could you explain me what is target in terms > > of lldb? > > > > Thanks in advance. > > > > Regards, > > Alexander Polyakov > > > > 2018-04-25 1:32 GMT+03:00 Ted Woodward <ted.woodw...@codeaurora.org>: > > > > 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
