[Lldb-commits] [PATCH] Move argument globbing to Target::Launch from Platform::LaunchProcess.

[Zachary Turner]

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 <gclayton at apple.com> 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 <zturner at google.com> 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
> > lldb-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20150219/20b8674b/attachment.html>