> On Aug 12, 2014, at 3:58 PM, Zachary Turner <[email protected]> wrote:
>
> Thanks, that makes sense. The problem is that Host::LaunchProcess doesn't
> really return anything useful. When I create a process on Windows, I get a
> HANDLE back that I can use to later manipulate the process. Note that this
> isn't the same as a Pid. I guess Host::LaunchProcess will return the pid in
> the launch_info structure,
Indeed it does.
> which I could then use to get another handle, but that would involve closing
> the first handle before I get the second handle, which I'm a little wary of,
> and I would feel better just using the original handle. But there's no
> obvious way to pass it back.
We can have the LaunchInfo contain the new "host" version of the process handle
which would need to be added to the lldb-types.h. We had spoke about this
before about possibly adding a:
namespace lldb {
namespace host {
typedef pid_t process_t;
}
}
On windows you could make this a process handle and add
lldb_private::ProcessInfo could have a new ivar added:
namespace lldb_private
{
class ProcessInfo
{
FileSpec m_executable;
std::string m_arg0; // argv[0] if supported. If empty, then use
m_executable.
// Not all process plug-ins support specifying an argv[0]
// that differs from the resolved platform executable
// (which is in m_executable)
Args m_arguments; // All program arguments except argv[0]
Args m_environment;
uint32_t m_uid;
uint32_t m_gid;
ArchSpec m_arch;
lldb::pid_t m_pid;
lldb::host::process_t m_process_handle; // <<<<< new ivar
};
>
> I'm not sure what the right abstraction is here that would make sense on all
> platforms, but I feel like what is needed is some kind of NativeProcess
> class, and LaunchProcess's signature could change to this:
I believe the lldb::host::process_t should be enough. It can be a class if
needed for your system, or it can just be a quick typedef like above.
>
> static Error
> Host::LaunchProcess (ProcessLaunchInfo &launch_info, NativeProcess **process);
>
> If the user passes in NULL, then we just clean up the process handle (or do
> nothing, depending on platform), and if it's not NULL, then Host allocates
> the appropriate type of Platform specific Process object. For example, it
> allocates a NativeProcessLinux, or a NativeProcessMacOSX, or a
> NativeProcessWindows, etc.
>
> Do you think something like this could work? Or maybe have other ideas?
I would update the ProcessInfo (ProcessInstanceInfo inherits from it) since
this also ties into the platform functions that find and get info for processes:
virtual uint32_t
Platform::FindProcesses (const ProcessInstanceInfoMatch &match_info,
ProcessInstanceInfoList &proc_infos);
virtual bool
Platform::GetProcessInfo (lldb::pid_t pid, ProcessInstanceInfo
&proc_info);
And it would be nice to get these native process handles there as well.
Greg
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
