On Dec 9, 2013, at 10:41 AM, Jean-Daniel Dupas <[email protected]> wrote:
> Hello, > > While working on a Mach native process, I saw there is actually two code > paths to launch a process in the debugger. > > One that query the platform using CanDebugProcess() and then call > Platform::DebugProcess, which end up doing: > - Launch Process. > - Ask target to Create a Process instance. > - Use the process instance to Attach to the freshly launched process. > > and a second code path that: > - Ask the target to create a process instance. > - Use the process instance to Launch the process to debug. > > Why do we need two code paths to do basically the same thing, especially as > all processes, included the GDBRemote one supports Launch, but no platform > but the Darwin one supports the first code path. > > Wouldn't it be simpler to just let the process take care of the Launch part > in all cases ? It currently relies on the platform which is good. Why? Because if you are debugging something on a remote system, it will use the same code path as the current host system (the platform does the launching for debugging). Underneath it all, everyone should be using the Host::LaunchProcess(), so the posix_spawn() code should be the same no matter which way things get launched. Another reason to leave things the way they are is if you have a simulator platform, like "ios-simulator", and it uses a native application that runs on the local host using native code, you might want your "simulator" platform to include extra mandatory environment variables when launching and/or do some special handshake with the simulator prior to or after launching, even though it is just a native application. If we don't let the platforms do the launching, then we have to have all sorts of platform functions that would be called prior to and after launching... This means that the Process::Launch() is probably not needed if we can get all platforms to handle launching the process. I don't believe that any platforms other than the native darwin platform and the iOS platform handle launching right now, so it was done partially to move the darwin side over to the latest and greatest and yet leaving the other native debugging alone so they continue to work. Greg _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
