> On Apr 24, 2018, at 2:35 PM, Jim Ingham <jing...@apple.com> wrote:
> 
> 
> 
>> On Apr 24, 2018, at 9:44 AM, Greg Clayton <clayb...@gmail.com> wrote:
>> 
>> 
>> 
>>> On Apr 24, 2018, at 9:37 AM, Jim Ingham <jing...@apple.com> wrote:
>>> 
>>>> 
>>>> On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev 
>>>> <lldb-dev@lists.llvm.org> wrote:
>>>> 
>>>> Welcome Alexander!
>>> 
>>> Yes, welcome!
>>> 
>>>> 
>>>> The title might be more stated as "Reimplement lldb-mi to correctly use 
>>>> the SB API instead of using HandleCommand and regular expressions to parse 
>>>> the command results" as it is already using the SB API, just not using it 
>>>> anywhere close to correctly! 
>>>> 
>>>> I look forward to seeing the changes. 
>>>> 
>>>> A few things I ran into when playing with lldb-mi:
>>>> - file-exec or exec-file packet might come _after_ some breakpoints are 
>>>> set. We should make sure we create a lldb::SBTarget right away and set the 
>>>> breakpoints on the empty target so that we don't miss these breakpoints if 
>>>> this is still an issue. Then the when we receive the exec-file packet, we 
>>>> set the file on the target
>>> 
>>> Breakpoints set before any target is created are set on the dummy target.  
>>> Breakpoints on the dummy target are copied into any new targets.  So this 
>>> should not be necessary.  If that wasn't working we should figure that out, 
>>> but it's not the responsibility of the MI to get this right.
>> 
>> We are trying not to use the command line and the command line is what uses 
>> the dummy target automatically. When using the SB API you use a 
>> lldb::SBTarget to set the breakpoint on so you need a target. What do you 
>> suggest we use for the target? I would rather the lldb-mi code not rely on 
>> the currently selected target or the dummy target.
> 
> lldb-MI models gdb's behavior, which is one debugger with one target.  There 
> is no command to add or switch to targets, etc.  So it doesn't seem 
> unreasonable for MI to keep track of its one actual target and if that is 
> empty, use SBDebugger::GetDummyTarget.  The other option is to make a blank 
> target up front and then add files to it when you see the -file-exec command. 
> But that seems more error-prone than using the mechanism lldb provides for 
> doing things before you have a target.  Again, if we were modeling an API 
> that could switch targets we might want to do something more clever.  But 
> that isn't how the GDB-MI was set up to work.
> 

lldb-mi code may or may not have a target when it needs one. If it doesn't have 
a target, use the SB API to get the dummy target and use that. 

Jim: is the dummy target good for anything other than adding breakpoints to? 
What all gets copied from a the dummy target to the new target when one gets 
created?

Alexander, feel free to ask questions if you didn't understand any of the above 
information. 



> Jim
> 
> 
>> 
>>> 
>>>> - remove all uses of HandleCommand and use SB APIs where possible
>>>> - Add any SB API that might be missing and require us to use HandleCommand
>>>> 
>>> 
>>> The rest of these seem good guidelines.
>>> 
>>> Jim
>>> 
>>> 
>>>> Good luck and let us know if you have any questions,
>>>> 
>>>> Greg Clayton
>>>> 
>>>> 
>>>>> On Apr 23, 2018, at 3:19 PM, Adrian Prantl via lldb-dev 
>>>>> <lldb-dev@lists.llvm.org> wrote:
>>>>> 
>>>>> Please join me in welcoming Alexander Polyakov, who will be working on 
>>>>> cleaning up and completing LLDB's lldb-mi fronted as part of his Google 
>>>>> Summer Of Code project:
>>>>> 
>>>>> Reimplement lldb-mi on top of the LLDB public SB API
>>>>> https://summerofcode.withgoogle.com/projects/#5427847301169152
>>>>> 
>>>>> -- adrian
>>>>> _______________________________________________
>>>>> lldb-dev mailing list
>>>>> lldb-dev@lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>> 
>>>> _______________________________________________
>>>> lldb-dev mailing list
>>>> lldb-dev@lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

Reply via email to