Re: [lldb-dev] Welcome Alexander!

[Jim Ingham via lldb-dev]

> On Apr 24, 2018, at 5:24 PM, Александр Поляков  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 :
> 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, Александр Поляков  
> > 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 :
> > 
> > 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 " 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 
> > > Cc: LLDB 
> > > Subject: Re: [lldb-dev] Welcome Alexander!
> > > 
> > > 
> > > 
> > > > On Apr 24, 2018, at 3:08 PM, Greg Clayton  wrote:
> > > >
> > > >
> > > >
> > > >> On Apr 24, 2018, at 3:00 PM, Jim Ingham  wrote:
> > > >>
> > > 

Re: [lldb-dev] Welcome Alexander!

[Александр Поляков via lldb-dev]

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 :

> 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, Александр Поляков 
> 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 :
> >
> > 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 " 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 
> > > Cc: LLDB 
> > > Subject: Re: [lldb-dev] Welcome Alexander!
> > >
> > >
> > >
> > > > On Apr 24, 2018, at 3:08 PM, Greg Clayton 
> wrote:
> > > >
> > > >
> > > >
> > > >> On Apr 24, 2018, at 3:00 PM, Jim Ingham  wrote:
> > > >>
> > > >>
> > > >>
> > > >>> On Apr 24, 2018, at 2:46 PM, Greg Clayton 
> wrote:
> > > >>>
> > > >>>
> > > >>>
> > >  On Apr 24, 2018, at 2:35 PM, Jim Ingham 
> wrote:
> > > 
> > > 
> > > 
> > > > On Apr 24, 2018, at 9:44 AM, Greg Clayton 
> > > wrote:
> > > >
> > > >
> > > >
> > > >> On Apr 24, 2018, at 9:37 AM, Jim Ingham 
> > > wrote:
> > > >>
> > > >>>
> > > >>> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev  > > 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
> > > 

Re: [lldb-dev] Welcome Alexander!

[Jim Ingham via lldb-dev]

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, Александр Поляков  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 :
> 
> 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 " 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 
> > Cc: LLDB 
> > Subject: Re: [lldb-dev] Welcome Alexander!
> > 
> > 
> > 
> > > On Apr 24, 2018, at 3:08 PM, Greg Clayton  wrote:
> > >
> > >
> > >
> > >> On Apr 24, 2018, at 3:00 PM, Jim Ingham  wrote:
> > >>
> > >>
> > >>
> > >>> On Apr 24, 2018, at 2:46 PM, Greg Clayton  wrote:
> > >>>
> > >>>
> > >>>
> >  On Apr 24, 2018, at 2:35 PM, Jim Ingham  wrote:
> > 
> > 
> > 
> > > On Apr 24, 2018, at 9:44 AM, Greg Clayton 
> > wrote:
> > >
> > >
> > >
> > >> On Apr 24, 2018, at 9:37 AM, Jim Ingham 
> > wrote:
> > >>
> > >>>
> > >>> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev  > 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
> > >>
> > 

Re: [lldb-dev] Welcome Alexander!

[Александр Поляков via lldb-dev]

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 :

>
> 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 " 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 
> > Cc: LLDB 
> > Subject: Re: [lldb-dev] Welcome Alexander!
> >
> >
> >
> > > On Apr 24, 2018, at 3:08 PM, Greg Clayton  wrote:
> > >
> > >
> > >
> > >> On Apr 24, 2018, at 3:00 PM, Jim Ingham  wrote:
> > >>
> > >>
> > >>
> > >>> On Apr 24, 2018, at 2:46 PM, Greg Clayton 
> wrote:
> > >>>
> > >>>
> > >>>
> >  On Apr 24, 2018, at 2:35 PM, Jim Ingham  wrote:
> > 
> > 
> > 
> > > On Apr 24, 2018, at 9:44 AM, Greg Clayton 
> > wrote:
> > >
> > >
> > >
> > >> On Apr 24, 2018, at 9:37 AM, Jim Ingham 
> > wrote:
> > >>
> > >>>
> > >>> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev  > 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
> > 

Re: [lldb-dev] Welcome Alexander!

[Ted Woodward via lldb-dev]

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 " 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 
> Cc: LLDB 
> Subject: Re: [lldb-dev] Welcome Alexander!
> 
> 
> 
> > On Apr 24, 2018, at 3:08 PM, Greg Clayton  wrote:
> >
> >
> >
> >> On Apr 24, 2018, at 3:00 PM, Jim Ingham  wrote:
> >>
> >>
> >>
> >>> On Apr 24, 2018, at 2:46 PM, Greg Clayton  wrote:
> >>>
> >>>
> >>>
>  On Apr 24, 2018, at 2:35 PM, Jim Ingham  wrote:
> 
> 
> 
> > On Apr 24, 2018, at 9:44 AM, Greg Clayton 
> wrote:
> >
> >
> >
> >> On Apr 24, 2018, at 9:37 AM, Jim Ingham 
> wrote:
> >>
> >>>
> >>> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev  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
> 

Re: [lldb-dev] Welcome Alexander!

[Jim Ingham via lldb-dev]

> On Apr 24, 2018, at 3:08 PM, Greg Clayton  wrote:
> 
> 
> 
>> On Apr 24, 2018, at 3:00 PM, Jim Ingham  wrote:
>> 
>> 
>> 
>>> On Apr 24, 2018, at 2:46 PM, Greg Clayton  wrote:
>>> 
>>> 
>>> 
 On Apr 24, 2018, at 2:35 PM, Jim Ingham  wrote:
 
 
 
> On Apr 24, 2018, at 9:44 AM, Greg Clayton  wrote:
> 
> 
> 
>> On Apr 24, 2018, at 9:37 AM, Jim Ingham  wrote:
>> 
>>> 
>>> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev 
>>>  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 
  wrote:
 
 Please join me in welcoming Alexander Polyakov, who will be working on 
 cleaning up 

Re: [lldb-dev] Welcome Alexander!

[Greg Clayton via lldb-dev]

> On Apr 24, 2018, at 3:00 PM, Jim Ingham  wrote:
> 
> 
> 
>> On Apr 24, 2018, at 2:46 PM, Greg Clayton  wrote:
>> 
>> 
>> 
>>> On Apr 24, 2018, at 2:35 PM, Jim Ingham  wrote:
>>> 
>>> 
>>> 
 On Apr 24, 2018, at 9:44 AM, Greg Clayton  wrote:
 
 
 
> On Apr 24, 2018, at 9:37 AM, Jim Ingham  wrote:
> 
>> 
>> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev 
>>  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.

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

Re: [lldb-dev] Welcome Alexander!

[Jim Ingham via lldb-dev]

> On Apr 24, 2018, at 2:46 PM, Greg Clayton  wrote:
> 
> 
> 
>> On Apr 24, 2018, at 2:35 PM, Jim Ingham  wrote:
>> 
>> 
>> 
>>> On Apr 24, 2018, at 9:44 AM, Greg Clayton  wrote:
>>> 
>>> 
>>> 
 On Apr 24, 2018, at 9:37 AM, Jim Ingham  wrote:
 
> 
> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev 
>  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 
>>  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

Re: [lldb-dev] Welcome Alexander!

[Greg Clayton via lldb-dev]

> On Apr 24, 2018, at 2:35 PM, Jim Ingham  wrote:
> 
> 
> 
>> On Apr 24, 2018, at 9:44 AM, Greg Clayton  wrote:
>> 
>> 
>> 
>>> On Apr 24, 2018, at 9:37 AM, Jim Ingham  wrote:
>>> 
 
 On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev 
  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?

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

Re: [lldb-dev] Welcome Alexander!

[Jim Ingham via lldb-dev]

> On Apr 24, 2018, at 9:44 AM, Greg Clayton  wrote:
> 
> 
> 
>> On Apr 24, 2018, at 9:37 AM, Jim Ingham  wrote:
>> 
>>> 
>>> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev 
>>>  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.

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

Re: [lldb-dev] Dlopen extremely slow while LLDB is attached

[Greg Clayton via lldb-dev]

> On Apr 24, 2018, at 12:26 PM, Scott Funkenhauser via lldb-dev 
>  wrote:
> 
> Hey guys,
> 
> I'm trying to track down an issue I'm seeing where dlopen takes significantly 
> longer to execute when LLDB is attached vs GDB (I've attached a simple 
> program that I used to reproduce the issue).
> I was wondering if anybody had any idea what might be contributing to the 
> additional execution time?
> Running without any debugger attached:
> $ ./lldb-load-sample
> Handle: 0x55768c80
> Done loading. 848.27ms
> $ ./lldb-load-sample
> Handle: 0x55768c80
> Done loading. 19.6047ms
> 
> I noticed that the first run was significantly slower than any subsequent 
> runs. Most likely due to some caching in Linux.
> 
> 
> For LLDB:
> (lldb) file lldb-load-sample
> Current executable set to 'lldb-load-sample' (x86_64).
> (lldb) run
> Process 82804 launched: '/lldb-load-sample' (x86_64)
> Handle: 0x55768c80
> Done loading. 5742.78ms
> Process 82804 exited with status = 0 (0x) 
> (lldb) run
> Process 83454 launched: '/lldb-load-sample' (x86_64)
> Handle: 0x55768c80
> Done loading. 19.4184ms
> Process 83454 exited with status = 0 (0x)
> 
> I noticed that subsequent runs were much faster (most likely due to some 
> caching in Linux / LLDB), but that isn't relevant in my situation. Exiting 
> LLDB and starting a new LLDB process still has an extremely long first run 
> (In this case ~5.5s). There are other real world cases (initializing Vulkan 
> which does a bunch of dlopens) where this can add 10s of seconds really 
> slowing down iteration time.
> 
> 
> For GDB:
> (gdb) file lldb-load-sample
> Reading symbols from a.out...done.
> (gdb) run
> Starting program: /lldb-load-sample
> Handle: 0x55768c80
> Done loading. 79.7276ms
> [Inferior 1 (process 85063) exited normally]
> (gdb) run
> Starting program: /lldb-load-sample
> Handle: 0x55768c80
> Done loading. 80.325ms
> [Inferior 1 (process 85063) exited normally]
> 
> As you can see the first run is slightly slower than running without a 
> debugger attached, but it's not enough to be noticeable.

I would venture to say LLDB is indexing the debug info during the shared 
library load breakpoint for some reason. GDB might not have any breakpoints or 
symbols to find to do in the shared library, so it might not end up parsing 
anything. So my guess is LLDB is looking for a symbol in any shared library 
that is loaded and when the shared library gets loaded it causes LLDB to do 
more work. All of LLDB's breakpoints are always looking for new locations to 
resolve (file and line breakpoints, breakpoints by name, and other plug-ins 
might be looking for things). You might try enabling with:

(lldb) log enable --timestamp --file /tmp/log.txt dwarf info
(lldb) file lldb-load-sample
(lldb) run
(lldb) quit

then see if you can see any delays inside of LLDB.

Greg


___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Dlopen extremely slow while LLDB is attached

[Scott Funkenhauser via lldb-dev]

No liblldb.so didn't have any debug information, I made sure to strip it.
With debug information it was 1.7GB which took way too long to load for a
practical reproduction case.

On Tue, Apr 24, 2018 at 3:36 PM Jason Molenda  wrote:

> Was liblldb.so build with debug information?  You're probably looking at
> lldb scanning the DWARF to make up its symbol table.  That would be re-used
> on subsequent reruns so you're only seeing the cost that first time
> through.  gdb may be using the standard dwarf accelerator tables, or it may
> be delaying the cost of the scan until you try to do something like a
> breakpoint by name.
>
>
> J
>
> > On Apr 24, 2018, at 12:26 PM, Scott Funkenhauser via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hey guys,
> >
> > I'm trying to track down an issue I'm seeing where dlopen takes
> significantly longer to execute when LLDB is attached vs GDB (I've attached
> a simple program that I used to reproduce the issue).
> > I was wondering if anybody had any idea what might be contributing to
> the additional execution time?
> >
> > Running without any debugger attached:
> > $ ./lldb-load-sample
> > Handle: 0x55768c80
> > Done loading. 848.27ms
> > $ ./lldb-load-sample
> > Handle: 0x55768c80
> > Done loading. 19.6047ms
> >
> > I noticed that the first run was significantly slower than any
> subsequent runs. Most likely due to some caching in Linux.
> >
> >
> > For LLDB:
> > (lldb) file lldb-load-sample
> > Current executable set to 'lldb-load-sample' (x86_64).
> > (lldb) run
> > Process 82804 launched: '/lldb-load-sample' (x86_64)
> > Handle: 0x55768c80
> > Done loading. 5742.78ms
> > Process 82804 exited with status = 0 (0x)
> > (lldb) run
> > Process 83454 launched: '/lldb-load-sample' (x86_64)
> > Handle: 0x55768c80
> > Done loading. 19.4184ms
> > Process 83454 exited with status = 0 (0x)
> >
> > I noticed that subsequent runs were much faster (most likely due to some
> caching in Linux / LLDB), but that isn't relevant in my situation. Exiting
> LLDB and starting a new LLDB process still has an extremely long first run
> (In this case ~5.5s). There are other real world cases (initializing Vulkan
> which does a bunch of dlopens) where this can add 10s of seconds really
> slowing down iteration time.
> >
> >
> > For GDB:
> > (gdb) file lldb-load-sample
> > Reading symbols from a.out...done.
> > (gdb) run
> > Starting program: /lldb-load-sample
> > Handle: 0x55768c80
> > Done loading. 79.7276ms
> > [Inferior 1 (process 85063) exited normally]
> > (gdb) run
> > Starting program: /lldb-load-sample
> > Handle: 0x55768c80
> > Done loading. 80.325ms
> > [Inferior 1 (process 85063) exited normally]
> >
> > As you can see the first run is slightly slower than running without a
> debugger attached, but it's not enough to be noticeable.
> >
> > Thanks,
> > Scott
> >
> > ___
> > 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

Re: [lldb-dev] Dlopen extremely slow while LLDB is attached

[Jason Molenda via lldb-dev]

Was liblldb.so build with debug information?  You're probably looking at lldb 
scanning the DWARF to make up its symbol table.  That would be re-used on 
subsequent reruns so you're only seeing the cost that first time through.  gdb 
may be using the standard dwarf accelerator tables, or it may be delaying the 
cost of the scan until you try to do something like a breakpoint by name.  


J

> On Apr 24, 2018, at 12:26 PM, Scott Funkenhauser via lldb-dev 
>  wrote:
> 
> Hey guys,
> 
> I'm trying to track down an issue I'm seeing where dlopen takes significantly 
> longer to execute when LLDB is attached vs GDB (I've attached a simple 
> program that I used to reproduce the issue).
> I was wondering if anybody had any idea what might be contributing to the 
> additional execution time?
> 
> Running without any debugger attached:
> $ ./lldb-load-sample
> Handle: 0x55768c80
> Done loading. 848.27ms
> $ ./lldb-load-sample
> Handle: 0x55768c80
> Done loading. 19.6047ms
> 
> I noticed that the first run was significantly slower than any subsequent 
> runs. Most likely due to some caching in Linux.
> 
> 
> For LLDB:
> (lldb) file lldb-load-sample
> Current executable set to 'lldb-load-sample' (x86_64).
> (lldb) run
> Process 82804 launched: '/lldb-load-sample' (x86_64)
> Handle: 0x55768c80
> Done loading. 5742.78ms
> Process 82804 exited with status = 0 (0x) 
> (lldb) run
> Process 83454 launched: '/lldb-load-sample' (x86_64)
> Handle: 0x55768c80
> Done loading. 19.4184ms
> Process 83454 exited with status = 0 (0x)
> 
> I noticed that subsequent runs were much faster (most likely due to some 
> caching in Linux / LLDB), but that isn't relevant in my situation. Exiting 
> LLDB and starting a new LLDB process still has an extremely long first run 
> (In this case ~5.5s). There are other real world cases (initializing Vulkan 
> which does a bunch of dlopens) where this can add 10s of seconds really 
> slowing down iteration time.
> 
> 
> For GDB:
> (gdb) file lldb-load-sample
> Reading symbols from a.out...done.
> (gdb) run
> Starting program: /lldb-load-sample
> Handle: 0x55768c80
> Done loading. 79.7276ms
> [Inferior 1 (process 85063) exited normally]
> (gdb) run
> Starting program: /lldb-load-sample
> Handle: 0x55768c80
> Done loading. 80.325ms
> [Inferior 1 (process 85063) exited normally]
> 
> As you can see the first run is slightly slower than running without a 
> debugger attached, but it's not enough to be noticeable.
> 
> Thanks,
> Scott
> 
> ___
> 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] Dlopen extremely slow while LLDB is attached

[Scott Funkenhauser via lldb-dev]

Hey guys,

I'm trying to track down an issue I'm seeing where dlopen takes
significantly longer to execute when LLDB is attached vs GDB (I've attached
a simple program that I used to reproduce the issue).
I was wondering if anybody had any idea what might be contributing to the
additional execution time?

Running without any debugger attached:
$ ./lldb-load-sample
Handle: 0x55768c80
Done loading. 848.27ms
$ ./lldb-load-sample
Handle: 0x55768c80
Done loading. 19.6047ms

I noticed that the first run was significantly slower than any subsequent
runs. Most likely due to some caching in Linux.


For LLDB:
(lldb) file lldb-load-sample
Current executable set to 'lldb-load-sample' (x86_64).
(lldb) run
Process 82804 launched: '/lldb-load-sample' (x86_64)
Handle: 0x55768c80
Done loading. 5742.78ms
Process 82804 exited with status = 0 (0x)
(lldb) run
Process 83454 launched: '/lldb-load-sample' (x86_64)
Handle: 0x55768c80
Done loading. 19.4184ms
Process 83454 exited with status = 0 (0x)

I noticed that subsequent runs were much faster (most likely due to some
caching in Linux / LLDB), but that isn't relevant in my situation. Exiting
LLDB and starting a new LLDB process still has an extremely long first run
(In this case ~5.5s). There are other real world cases (initializing Vulkan
which does a bunch of dlopens) where this can add 10s of seconds really
slowing down iteration time.


For GDB:
(gdb) file lldb-load-sample
Reading symbols from a.out...done.
(gdb) run
Starting program: /lldb-load-sample
Handle: 0x55768c80
Done loading. 79.7276ms
[Inferior 1 (process 85063) exited normally]
(gdb) run
Starting program: /lldb-load-sample
Handle: 0x55768c80
Done loading. 80.325ms
[Inferior 1 (process 85063) exited normally]

As you can see the first run is slightly slower than running without a
debugger attached, but it's not enough to be noticeable.

Thanks,
Scott
#include 
#include 
#include 
#include 

int main() {
  struct timespec start;
  clock_gettime(CLOCK_MONOTONIC, );

  // Used a stripped version of liblldb.so, as the unstripped version is 1.7GB
  // and takes too long to be a useful reproduction case.
  void* handle = dlopen("liblldb.so", RTLD_NOW | RTLD_GLOBAL);

  struct timespec stop;
  clock_gettime(CLOCK_MONOTONIC, );

  if (handle != 0) {
dlclose(handle);
  }

  long seconds, nseconds;
  seconds = stop.tv_sec - start.tv_sec;
  nseconds = stop.tv_nsec - start.tv_nsec;

  float duration = seconds * 1000 + nseconds / 100.0f;

  std::cout << "Handle: " << handle << std::endl;
  std::cout << "Done loading. " << duration << "ms" << std::endl;
}
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Welcome Alexander!

[Александр Поляков via lldb-dev]

​Thanks Greg,

I changed the title and abstract, please check it out.
https://summerofcode.withgoogle.com/projects/#5427847301169152​


Regards,
Alexander Polyakov

2018-04-24 19:44 GMT+03:00 Greg Clayton :

>
>
> On Apr 24, 2018, at 9:37 AM, Jim Ingham  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.
>
>
> - 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

Re: [lldb-dev] Welcome Alexander!

[Greg Clayton via lldb-dev]

> On Apr 24, 2018, at 9:37 AM, Jim Ingham  wrote:
> 
>> 
>> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev 
>> > 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.

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

Re: [lldb-dev] Welcome Alexander!

[Jim Ingham via lldb-dev]

> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev 
>  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.

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

Re: [lldb-dev] Welcome Alexander!

[Greg Clayton via lldb-dev]

Welcome Alexander!

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

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