<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 24, 2018, at 5:58 PM, Jim Ingham <<a href="mailto:jingham@apple.com" class="">jingham@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><br class=""><blockquote type="cite" class="">On Apr 24, 2018, at 5:24 PM, Александр Поляков <<a href="mailto:polyakov.alx@gmail.com" class="">polyakov.alx@gmail.com</a>> wrote:<br class=""><br class="">Thanks Jim, it helped me a lot.<br class=""><br class="">Can we do something like this: <br class=""> 1) having empty dummy target;<br class=""></blockquote><br class="">Yes, you don't need to do anything here. The Debugger object always makes a dummy target.<br class=""><br class=""><blockquote type="cite" class=""> 2) setting breakpoints to this dummy target until getting real file through -file-exec-and-symbols;<br class=""></blockquote><br class="">Right, the Debugger has an API: GetDummyTarget that will get this for you, and then you call GetDummyTarget().BreakpointCreate...<br class=""></div></div></blockquote><div><br class=""></div>It looks like all you will need to do is modify the existing CMICmnLLDBDebugSessionInfo::GetTarget() function from:</div><div><br class=""></div><div>lldb::SBTarget CMICmnLLDBDebugSessionInfo::GetTarget() const {<br class=""> return GetDebugger().GetSelectedTarget();<br class="">}<br class=""></div><div><br class=""></div><div>to:</div><div><br class=""></div><div><div>lldb::SBTarget CMICmnLLDBDebugSessionInfo::GetTarget() const {</div><div> auto target = GetDebugger().GetSelectedTarget();</div><div> if (target.IsValid())</div><div> return target;<br class=""> return GetDebugger().<span style="font-size: 11px; background-color: rgb(255, 255, 255);" class="">GetDummyTarget();</span><br class="">}<br class=""></div><div class=""><br class=""></div></div><div><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""> 3) creating new target and moving all breakpoints from dummy target to it;<br class=""></blockquote><br class="">The move will happen automatically.<br class=""></div></div></blockquote><div><br class=""></div>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.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""> 4) clearing all breakpoints from the dummy target;<br class=""></blockquote><br class="">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.<br class=""><br class=""><blockquote type="cite" class=""> 5) back to 1);<br class=""><br class=""></blockquote><br class="">Jim<br class=""><br class=""><blockquote type="cite" class=""><br class=""><br class=""><br class=""><br class=""><br class="">Regards,<br class="">Alexander Polyakov<br class=""><br class="">2018-04-25 2:56 GMT+03:00 Jim Ingham <<a href="mailto:jingham@apple.com" class="">jingham@apple.com</a>>:<br class="">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.<br class=""><br class="">But a Target need not have a file. For instance, if you do:<br class=""><br class="">$ lldb --pid 12345<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">Greg was worried that you could do:<br class=""><br class="">-break-set<br class="">-file-exec-and-symbols<br class=""><br class="">and he wanted to make sure that works. I think that's what you understood as well. <br class=""><br class="">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.<br class=""><br class="">Jim<br class=""><br class="">(*) one lldb process can also support multiple Debuggers, but that's another story...<br class=""><br class="">Jim<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Apr 24, 2018, at 4:41 PM, Александр Поляков <<a href="mailto:polyakov.alx@gmail.com" class="">polyakov.alx@gmail.com</a>> wrote:<br class=""><br class="">I don't completely understand how it possible to add breakpoint before choosing a file(did you mean -file-exec-and-symbols cmd?).<br class="">And another important thing: could you explain me what is target in terms of lldb?<br class=""><br class="">Thanks in advance.<br class=""><br class="">Regards,<br class="">Alexander Polyakov<br class=""><br class="">2018-04-25 1:32 GMT+03:00 Ted Woodward <<a href="mailto:ted.woodward@codeaurora.org" class="">ted.woodward@codeaurora.org</a>>:<br class=""><br class="">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.<br class=""><br class="">Ted<br class=""><br class="">--<br class="">Qualcomm Innovation Center, Inc.<br class="">The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<br class=""><br class=""><blockquote type="cite" class="">-----Original Message-----<br class="">From: lldb-dev [<a href="mailto:lldb-dev-bounces@lists.llvm.org" class="">mailto:lldb-dev-bounces@lists.llvm.org</a>] On Behalf Of Jim<br class="">Ingham via lldb-dev<br class="">Sent: Tuesday, April 24, 2018 5:19 PM<br class="">To: Greg Clayton <<a href="mailto:clayborg@gmail.com" class="">clayborg@gmail.com</a>><br class="">Cc: LLDB <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>><br class="">Subject: Re: [lldb-dev] Welcome Alexander!<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Apr 24, 2018, at 3:08 PM, Greg Clayton <<a href="mailto:clayborg@gmail.com" class="">clayborg@gmail.com</a>> wrote:<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Apr 24, 2018, at 3:00 PM, Jim Ingham <<a href="mailto:jingham@apple.com" class="">jingham@apple.com</a>> wrote:<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Apr 24, 2018, at 2:46 PM, Greg Clayton <<a href="mailto:clayborg@gmail.com" class="">clayborg@gmail.com</a>> wrote:<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Apr 24, 2018, at 2:35 PM, Jim Ingham <<a href="mailto:jingham@apple.com" class="">jingham@apple.com</a>> wrote:<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Apr 24, 2018, at 9:44 AM, Greg Clayton <<a href="mailto:clayborg@gmail.com" class="">clayborg@gmail.com</a>><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote>wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Apr 24, 2018, at 9:37 AM, Jim Ingham <<a href="mailto:jingham@apple.com" class="">jingham@apple.com</a>><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class=""><br class="">On Apr 24, 2018, at 7:43 AM, Greg Clayton via lldb-dev <lldb-<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><a href="mailto:dev@lists.llvm.org" class="">dev@lists.llvm.org</a>> wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">Welcome Alexander!<br class=""></blockquote><br class="">Yes, welcome!<br class=""><br class=""><blockquote type="cite" class=""><br class="">The title might be more stated as "Reimplement lldb-mi to correctly<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>use the SB API instead of using HandleCommand and regular expressions to<br class="">parse the command results" as it is already using the SB API, just not using it<br class="">anywhere close to correctly!<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">I look forward to seeing the changes.<br class=""><br class="">A few things I ran into when playing with lldb-mi:<br class="">- file-exec or exec-file packet might come _after_ some breakpoints<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>are set. We should make sure we create a lldb::SBTarget right away and set the<br class="">breakpoints on the empty target so that we don't miss these breakpoints if this<br class="">is still an issue. Then the when we receive the exec-file packet, we set the file<br class="">on the target<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">Breakpoints set before any target is created are set on the dummy<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>target. Breakpoints on the dummy target are copied into any new targets. So<br class="">this should not be necessary. If that wasn't working we should figure that out,<br class="">but it's not the responsibility of the MI to get this right.<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">We are trying not to use the command line and the command line is<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote>what uses the dummy target automatically. When using the SB API you use a<br class="">lldb::SBTarget to set the breakpoint on so you need a target. What do you<br class="">suggest we use for the target? I would rather the lldb-mi code not rely on the<br class="">currently selected target or the dummy target.<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">lldb-MI models gdb's behavior, which is one debugger with one target.<br class=""></blockquote></blockquote></blockquote></blockquote>There is no command to add or switch to targets, etc. So it doesn't seem<br class="">unreasonable for MI to keep track of its one actual target and if that is empty,<br class="">use SBDebugger::GetDummyTarget. The other option is to make a blank target<br class="">up front and then add files to it when you see the -file-exec command. But that<br class="">seems more error-prone than using the mechanism lldb provides for doing<br class="">things before you have a target. Again, if we were modeling an API that could<br class="">switch targets we might want to do something more clever. But that isn't how<br class="">the GDB-MI was set up to work.<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""></blockquote><br class="">lldb-mi code may or may not have a target when it needs one. If it doesn't<br class=""></blockquote></blockquote></blockquote>have a target, use the SB API to get the dummy target and use that.<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">Jim: is the dummy target good for anything other than adding breakpoints<br class=""></blockquote></blockquote></blockquote>to? What all gets copied from a the dummy target to the new target when one<br class="">gets created?<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">At present it only does breakpoints and stop hooks (see<br class=""></blockquote></blockquote>Target::PrimeFromDummyTarget.) I didn't do watchpoints since those are<br class="">seldom things you want to set generically, but you could probably add that.<br class="">Was there anything else you were thinking of?<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""></blockquote><br class="">No, just mostly trying to let Alexander know what he should use the Dummy<br class=""></blockquote>target for and also for my own knowledge. If there are MI clients that do other<br class="">things, we will need to know if we need to create an empty real target if they<br class="">aren't breakpoints or stop hooks.<br class=""><br class="">I can't think of any other things you add to a target like this. The settings get<br class="">inherited, and once you've started adding modules, I think you should create a<br class="">new target to hold them. But for anything interesting that's missing, as long as<br class="">they are copiable it would be easy to add them. Just call<br class="">GetSelectedOrDummyTarget when you go to set them, and then put the copy in<br class="">PrimeFromDummyTarget.<br class=""><br class=""><blockquote type="cite" class=""><br class="">Greg<br class=""><br class=""><blockquote type="cite" class="">Jim<br class=""><br class=""><blockquote type="cite" class=""><br class="">Alexander, feel free to ask questions if you didn't understand any of the<br class=""></blockquote></blockquote></blockquote>above information.<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">Jim<br class=""><br class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">- remove all uses of HandleCommand and use SB APIs where possible<br class="">- Add any SB API that might be missing and require us to use<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>HandleCommand<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""></blockquote><br class="">The rest of these seem good guidelines.<br class=""><br class="">Jim<br class=""><br class=""><br class=""><blockquote type="cite" class="">Good luck and let us know if you have any questions,<br class=""><br class="">Greg Clayton<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Apr 23, 2018, at 3:19 PM, Adrian Prantl via lldb-dev <lldb-<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><a href="mailto:dev@lists.llvm.org" class="">dev@lists.llvm.org</a>> wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">Please join me in welcoming Alexander Polyakov, who will be<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>working on cleaning up and completing LLDB's lldb-mi fronted as part of his<br class="">Google Summer Of Code project:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">Reimplement lldb-mi on top of the LLDB public SB API<br class=""><br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><a href="https://summerofcode.withgoogle.com/projects/#5427847301169152" class="">https://summerofcode.withgoogle.com/projects/#5427847301169152</a><br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="">-- adrian<br class="">_______________________________________________<br class="">lldb-dev mailing list<br class="">lldb-dev@lists.llvm.org<br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev<br class=""></blockquote><br class="">_______________________________________________<br class="">lldb-dev mailing list<br class="">lldb-dev@lists.llvm.org<br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev<br class=""></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><br class=""></blockquote><br class="">_______________________________________________<br class="">lldb-dev mailing list<br class="">lldb-dev@lists.llvm.org<br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev<br class=""></blockquote><br class=""><br class=""></blockquote><br class=""><br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></body></html>