Alternatively I could just override Platform::DebugProcess() in
PlatformWindows. It says in the header that you shouldn't need to do that,
but maybe that's still a cleaner solution than adding this other function.
On Wed, May 13, 2015 at 2:59 PM Zachary Turner <ztur...@google.com> wrote:
> In particular this code:
>
> error = LaunchProcess (launch_info);
> if (error.Success())
> {
> if (log)
> log->Printf ("Platform::%s LaunchProcess() call succeeded
> (pid=%" PRIu64 ")", __FUNCTION__, launch_info.GetProcessID ());
> if (launch_info.GetProcessID() != LLDB_INVALID_PROCESS_ID)
> {
> ProcessAttachInfo attach_info (launch_info);
> process_sp = Attach (attach_info, debugger, target, error);
>
> For Windows if you want to launch a program under the debugger the method
> you use launch to launch the process also does the attach at the same
> time. Until recently, PlatformWindows::CanDebugProcess() had been
> returning false, so it was falling back to calling Process::DoLaunch(),
> which has been working fine.
>
> I'm adding support for attaching to processes though, and this requires
> changing that function to return true. So now both launches and attaches
> go through this path of launching first, and then attaching, which causes
> the launch codepath to break.
>
> What is the correct way to handle this? Could I add a method to Platform
> called SupportsAtomicLaunchAndAttach() that if true will just call
> Process::DoLaunch() directly, and if false will continue down the existing
> codepath?
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
