[lldb-dev] Welcome Alexander!

Tue Apr 24 15:32:06 PDT 2018

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-bounces at lists.llvm.org] On Behalf Of Jim
> Ingham via lldb-dev
> Sent: Tuesday, April 24, 2018 5:19 PM
> To: Greg Clayton <clayborg at gmail.com>
> Cc: LLDB <lldb-dev at lists.llvm.org>
> Subject: Re: [lldb-dev] Welcome Alexander!
> 
> 
> 
> > On Apr 24, 2018, at 3:08 PM, Greg Clayton <clayborg at gmail.com> wrote:
> >
> >
> >
> >> On Apr 24, 2018, at 3:00 PM, Jim Ingham <jingham at apple.com> wrote:
> >>
> >>
> >>
> >>> On Apr 24, 2018, at 2:46 PM, Greg Clayton <clayborg at gmail.com> wrote:
> >>>
> >>>
> >>>
> >>>> On Apr 24, 2018, at 2:35 PM, Jim Ingham <jingham at apple.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>>> On Apr 24, 2018, at 9:44 AM, Greg Clayton <clayborg at gmail.com>
> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On Apr 24, 2018, at 9:37 AM, Jim Ingham <jingham at apple.com>
> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev <lldb-
> dev at 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 at 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 at lists.llvm.org
> >>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> lldb-dev mailing list
> >>>>>>> lldb-dev at lists.llvm.org
> >>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev