> On Apr 24, 2018, at 5:58 PM, Jim Ingham <[email protected]> wrote:
>
>
>
>> On Apr 24, 2018, at 5:24 PM, Александр Поляков <[email protected]>
>> 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...
It looks like all you will need to do is modify the existing
CMICmnLLDBDebugSessionInfo::GetTarget() function from:
lldb::SBTarget CMICmnLLDBDebugSessionInfo::GetTarget() const {
return GetDebugger().GetSelectedTarget();
}
to:
lldb::SBTarget CMICmnLLDBDebugSessionInfo::GetTarget() const {
auto target = GetDebugger().GetSelectedTarget();
if (target.IsValid())
return target;
return GetDebugger().GetDummyTarget();
}
>
>> 3) creating new target and moving all breakpoints from dummy target to it;
>
> The move will happen automatically.
Yes, nothing to do here unless we do anything other than setting breakpoints
and stop hooks. I don't believe MI does any stop hook stuff, so the only thing
we should be doing to a dummy target is setting breakpoints otherwise we will
lose any actions we take on the dummy target.
>
>> 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 <[email protected]>:
>> 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, Александр Поляков <[email protected]>
>>> 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 <[email protected]>:
>>>
>>> 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:[email protected]] On Behalf Of Jim
>>>> Ingham via lldb-dev
>>>> Sent: Tuesday, April 24, 2018 5:19 PM
>>>> To: Greg Clayton <[email protected]>
>>>> Cc: LLDB <[email protected]>
>>>> Subject: Re: [lldb-dev] Welcome Alexander!
>>>>
>>>>
>>>>
>>>>> On Apr 24, 2018, at 3:08 PM, Greg Clayton <[email protected]> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Apr 24, 2018, at 3:00 PM, Jim Ingham <[email protected]> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Apr 24, 2018, at 2:46 PM, Greg Clayton <[email protected]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Apr 24, 2018, at 2:35 PM, Jim Ingham <[email protected]> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Apr 24, 2018, at 9:44 AM, Greg Clayton <[email protected]>
>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Apr 24, 2018, at 9:37 AM, Jim Ingham <[email protected]>
>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev <lldb-
>>>> [email protected]> 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-
>>>> [email protected]> 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
>>>>>>>>>>>> [email protected]
>>>>>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> lldb-dev mailing list
>>>>>>>>>>> [email protected]
>>>>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>>
>>>>
>>>> _______________________________________________
>>>> lldb-dev mailing list
>>>> [email protected]
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>>
>>
>
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
