In http://reviews.llvm.org/D6965#116930, @clayborg wrote:
> The fix I requested should be easy to implement as noted above in the code > comments. > This will provide the cleanest implementation and allow of the most > flexibility in setting the environment variables (just modify SBLaunchInfo), > working directory (modify SBLaunchInfo), etc, then when you launch you get to > just use the launch info you have built up. Greg, we are talking about different things. Your patch looks good but it wouldn't work on test case which I described earlier: In http://reviews.llvm.org/D6965#110595, @ki.stfu wrote: > In http://reviews.llvm.org/D6965#110558, @jingham wrote: > > > So the way you set arguments when you launch a process through the SB API's > > (besides some old unstructured API's that we'll eventually deprecate) is > > through the SBLaunchInfo. You're adding another way to get and set the > > arguments that's independent of that. > > > > I'd rather we didn't create another way to specify launch arguments. You > > can already do that by creating an SBLaunchInfo with the appropriate args > > set, and use that for the launch. > > > > The SBTarget already provides a way to get the arguments > > (SBTarget::GetNumArguments/GetArgumentAtIndex.) If you need to provide a > > way to get the current or previous launch arguments then we should add an > > API to copy out the SBLaunchInfo that was used for the launch. That's not > > currently kept around so you may have to reconstruct it from bits sitting > > in the target, but that way we keep one structured way to get at all the > > launch parameters... > > > Yes, I had seen these functions but I was working on CLI support in MI mode. > My goal was to fix the following cases: > First: > > -file-exec-and-symbols ~/p/hello > -exec-arguments foo bar > -interpreter-exec command "r" > > > Second: > > -file-exec-and-symbols ~/p/hello > -interpreter-exec command "settings set target.run-args foo bar" > -exec-run > > > Your way didn't work because when we specify arguments via "settings set > target.run-args" they are stored as Debugger's property. Initially I had > tried to set and get argument directly but it was awful because > SBDebugger::GetInternalVariableValue returns arguments in dumped format, like: > > [0]: "--arg1" > [1]: "2nd arg" > [2]: "third_arg" > [4]: "fourth=\"4th arg\"" > > > Therefore I decided to extend public API. http://reviews.llvm.org/D6965 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
