> On Jan 30, 2015, at 1:29 PM, Ilia K <[email protected]> wrote: > > In http://reviews.llvm.org/D6965#115926, @clayborg wrote: > >> I stand by my recommendation. > > > But your recommendation can't be applied in this case (perhaps I explained it > poorly). > The "r" command creates LaunchInfo every time it's executed. If you look at > CommandObjectProcessLaunch you will see that LaunchInfo (which is passed into > Target::Launch) is a class member. And this way is used in many commands. I > can't create global LaunchInfo which will be used by these commands and MI. I > think it would be strange to use one global variable in CLI commands and MI > module because at the moment CommandObjectProcess.cpp looks like separate > module which implements and registers commands inside itself and it doesn't > provide any external symbols (only 1 class CommandObjectMultiwordProcess). I > can't use your recommendation here.
But yet somehow you are able to keep a SBTarget around that you can modify? Why can't you also keep a SBLaunchInfo? Am I missing something? > >> There are many commands that build up what is effectively a SBLaunchInfo and >> eventually a command that makes the program run. > > > I agree that LaunchInfo is much better than many-many arguments of Launch > method or than a lot of setters/getters for properties. But current > implementation of process commands doesn't allow me to use single LaunchInfo > for them and MI. I don't create an additional method for setting of > arguments. I just have made a wrapper for the existing method. Again, how are you playing with a SBTarget unless you make a new one for each MI command? > >> It is quite sad to see things like '-interpreter-exec command "r"' in a MI >> command log. Do you really expect all implementations of MI to implement GDB >> commands? Is a packet that says "-exe-launch"? The only thing that should be >> exposing command line execution is when the user types something. And the >> command interpreter could then be anything and GDB commands would not be >> expected to work. > > > huh. Perhaps you didn't face with that but it's impossible to specify an > architecture (what can be done by using "target create") or select a remote > platform and connect to it (using platform commands) or launch a program and > stop at entry (process launch -s) or load a python scripts (using script > commands) or ... and so on. > It's a known problem and GDB/MI allows to use CLI and MI commands > simultaneously. Also smart guys invented -interpreter-exec command (see what > this command is doing here > <https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Miscellaneous-Commands.html> > if it's not clear) and now we don't need to introduce a new syntax or > commands, we can use CLI commands instead. Surely there is a MI command to launch a process. > > Therefore I think '-interpreter-exec command "r"' is an important case which > should work too, also as the case when arguments are set up by "settings set > target.run-args" after that -exec-run is called. I agree that we need to support a few of the commands that many IDE's send out, but if this is coming from users, then I feel they should be able to adapt to a different command line. Yes lldb does support "r" and many other GDB counterparts, but not all. Let me know what the current model is and how you are currently modifying a target before launching it. If you are always creating a new target and then launching it, you should be able to create a launch info, modify it and launch, otherwise, you are somehow storing a SBTarget. Let me know what I am missing. Greg _______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
