> 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-dev@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-dev@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
