[Lldb-commits] [PATCH] Add -exec-arguments command

Greg Clayton clayborg at gmail.com
Fri Jan 30 14:49:50 PST 2015


> On Jan 30, 2015, at 1:29 PM, Ilia K <ki.stfu at gmail.com> 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





More information about the lldb-commits mailing list