On Linux the platform is used to launch a process only when LLGS_LOCAL mode is on - otherwise, process plugin is used.
I'm wondering whether we need the standalone binary argdumper for globbing - potentially, we may just use glob function on Linux and OSX. For remote execution there might be a new protocol extension command (e.g., qGlobArgs) which either calls glob or runs argdumper. On Thu, Feb 19, 2015 at 3:12 PM, Zachary Turner <[email protected]> wrote: > There's currently a lot of ways to launch processes, and the interactions > that lead to specific methods being chosen can be a bit confusing sometimes. > > Out of curiosity, if a plugin supports launching under a debugger > directly, why is the separate start stopped / attach / resume algorithm > used? It seems more straightforward. > > If someone gets themselves through that codepath, argdumper won't be > used. Which is confusing if you're outside looking in at the API. From > the outside you just see the process gets launched using a supported > mechanism for launching processes, and it ignores the flag. > > On Thu Feb 19 2015 at 3:03:16 PM Greg Clayton <[email protected]> wrote: > >> They will only if you teach your platform to launch your processes. I >> believe the Windows platform is the only platform that doesn't do process >> launching via the platform. Am I wrong? If your platform supports it, it >> should launch your process in a stopped state and then your Process plug-in >> is simply asked to attach to that process. >> >> So if you wanted this to be supported, you will need to teach your >> windows platform to support the PlatformWindows::GlobArguments() which >> means you will launch the arg_dumper though cmd.exe and let the cmd.exe do >> any glowing and any expansion that it wants to, and parse the output. >> >> Enrico will check in a method for PlatformPOSIX::GlobArguments() which >> launches through a shell. I can't remember where we can get the default >> shell, but I seem to remember that we have the default shell that we can >> get from the host, so we could add this implementation in >> "Platform::GlobArguments()" and if "IsHost()" returns true, get the default >> shell from the host and launch the arg_dumper and then parse the output. >> >> This probably should be a method on ProcessLaunchInfo so that it fixes up >> its arguments and uses the target's platform to do the glob expansion. >> >> So the changes would be: >> 1 - add a method to ProcessLaunchInfo that gets passed a target and >> allows it to fixup arguments and environment variables in a new >> ProcessLaunchInfo: >> Error ProcessLaunchInfo::GlobArguments(Target &target, >> ProcessLaunchInfo &new_launch_info); >> 2 - if eLaunchFlagGlobArguments is set, then call the new >> ProcessLaunchInfo::GlobArguments() function before doing any launches >> 3 - Add a Platform::GlobArguments() function that, for the current host, >> knows how to run the arg_dumper on the current host using the >> Host::GetDefaultShell(). >> >> Then we need to figure out what to do for remote platforms. I am not sure >> we can guarantee there is an arg_dumper on the other side. For the >> lldb-platform, we could ensure that it has access to arg_dumper and can run >> it as a remote packet and return the results. >> >> Greg >> >> > On Feb 19, 2015, at 2:29 PM, Zachary Turner <[email protected]> wrote: >> > >> > Enrico, will your planned changes address the original issue? Namely, >> that >> > if a process is launched through the process plugin with the >> > eLaunchFlagGlobArguments flag set, after your changes will the arguments >> > correctly go through the globber first? >> > >> > >> > http://reviews.llvm.org/D7743 >> > >> > EMAIL PREFERENCES >> > http://reviews.llvm.org/settings/panel/emailpreferences/ >> > >> > >> > >> > _______________________________________________ >> > lldb-commits mailing list >> > [email protected] >> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits >> >> -- Oleksiy Vyalov | Software Engineer | [email protected]
_______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
