This way, the process will recieve globbed arguments even if it was
launched via the process plugin.
Details
- Reviewers
ovyalov zturner clayborg granata.enrico
Diff Detail
Event Timeline
Will let Enrico comment on the overall correctness of this. I'll just mention that I pushed a change to the original version of this that added some stuff for fixing Windows paths. You'll likely get a merge conflict when you rebase. Please make sure the changes I made stay in, because they will be needed for Windows even with this patch.
Thanks for the review ovyalov and zturner.
I will test remote Linux->Linux and report.
Per the current design, the globbing feature will not work for remote debugging. Enrico has mentioned that he is working on the generalizing this feature. Until then, I do not see any harm in putting this in. Will commit shortly.
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?
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.