[lldb-dev] Welcome Alexander!

Tue Apr 24 17:24:38 PDT 2018

Thanks Jim, it helped me a lot.

Can we do something like this:
   1) having empty dummy target;
   2) setting breakpoints to this dummy target until getting real file
through -file-exec-and-symbols;
   3) creating new target and moving all breakpoints from dummy target to
it;
   4) clearing all breakpoints from the dummy target;
   5) back to 1);

Regards,
Alexander Polyakov

2018-04-25 2:56 GMT+03:00 Jim Ingham <jingham at 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.alx at 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.woodward at 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-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
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20180425/1e53715c/attachment-0001.html>