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 > On Jul 10, 2014, at 9:39 AM, Zachary Turner <[email protected]> wrote: > > 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. > > > On Wed, Jul 9, 2014 at 2:05 PM, Greg Clayton <[email protected]> wrote: > > > On Jul 8, 2014, at 5:05 PM, Zachary Turner <[email protected]> wrote: > > > > 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 > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
