ProcessInstanceInfoList and mixed platform types

Is there any reason for a single instance of a ProcessInstanceInfoList to ever contain processes from multiple platforms all in the same list?

I’m trying to figure out if there’s a good way to separate out the platform specific details of a Process / ProcessInstanceInfo / ProcessLaunchInfo / ProcessAttachInfo and this is coming into play.

For example, if there’s no way for processes from two different platforms to be in the same list, then in theory these classes could be templatized with a “Details” class, and you could have, for example, a PosixProcessDetails and a WindowsProcessDetails.

I feel like at a high level, the core debugger shouldn’t really care about platform specific details, and it’s there now as a matter of convenience (e.g. for easy dumping). So if there’s a better way to represent this, it seems like it would be beneficial.

Is there any reason for a single instance of a ProcessInstanceInfoList to ever contain processes from multiple platforms all in the same list?

It really depends on what you are connecting to. For desktop, they will all probably be similar. But when a bare board JTAG connection lists the processes (which in the bare board case means core groups), then they might have some differences.

I'm trying to figure out if there's a good way to separate out the platform specific details of a Process / ProcessInstanceInfo / ProcessLaunchInfo / ProcessAttachInfo and this is coming into play.

For example, if there's no way for processes from two different platforms to be in the same list, then in theory these classes could be templatized with a "Details" class, and you could have, for example, a PosixProcessDetails and a WindowsProcessDetails.

This could be implemented, but we will need to make sure that any plug-ins that use ProcessLaunchInfo and ProcessAttachInfo doesn't require anything from the ProcessDetails class, or if they do, have some sort of llvm::dyn_cast operator to they can extra the required details from PosixProcessDetails or WindowsProcessDetails directly.

I feel like at a high level, the core debugger shouldn't really care about platform specific details, and it's there now as a matter of convenience (e.g. for easy dumping). So if there's a better way to represent this, it seems like it would be beneficial.

Feel free to submit a patch by specializing the details into classes as you state above. If these details aren't needed for attaching or launching, then I guess this will just help pretty printing. Is your motivation to avoid seeing the extra posix style info in some dumps?

Greg

Partly that, and partly as a matter of design. Anything that is platform specific should in theory only be used by code which has knowledge of that platform. So probably in the Host or Platform layers.

If I only want to avoid seeing platform-specific details in the dump, I could move the dump functions into a Dump class, and have a WindowsProcessDumper and a PosixProcessDumper. That’s a fine solution to that problem, but I was also just trying to think about if there’s a better way to separate out the functionality in the classes as a matter of design principle.

We've also talked about exposing platform specific process details by having the process class also expose a dictionary of "extra information". That way generic code could do stuff like "print everything you know about the process" and include the platform specific stuff without having to do too much magic. This would also make it easier to expose this info to the SB & Python layers.

Jim