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