You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great if you could have watch views locked to a specific process (or perhaps more generically an address space). This is important for debugging multi-processes at once. For example, if you are debugging 2 (or more) instances the same process and want to inspect a global variable. Well from which process does the debugger choose to show the variable from ? The user needs to have the ability to choose somehow. Maybe being able to specify the process in a view rule would be better ??
Related, I see you default to not attaching to child processes. Could you please add a checkbox in the targets UI for enabling this. This is pretty important for debugging web browsers - which use multi-process for sandbox isolation.
Thanks.
The text was updated successfully, but these errors were encountered:
Yeah I think in general there needs to be an extension to the evaluation language for selecting processes/modules, like VS has, and then defaulting to whatever thread (& thus module/process) is selected. I think this makes more sense than view rules, because it allows applying this throughout an expression tree, e.g. a.exe!global == b.exe!global. Currently the debugger should be doing that default rule, but I need to add the selection mechanism.
I've added a per-target option for defaultly attaching to child processes or not (although the checkbox will need to wait, as it is blocked on some further progress on the visualization system - as the targets view is now just a watch window - so it is just a 1 or 0 text field for now).
That extension sounds good. However it would only allow you to distinguish between different executable's ? Where you also need to be able to distinguish across different processes (address spaces). Say you are debugging 2 instances of the same a.exe and want to cast a pointer in the second instances address space to some type (U32*)0x123456678. Right now I think it would default to using the first instances address space? Similarly for the memory view (or any view that uses an address space) you would want a way of explicitly specifying which address space you want to look at.
However it would only allow you to distinguish between different executable's
I think I will end up having many ways of narrowing down the address space / selection. It's a little fuzzy, because e.g. something like a.exe can mean (a) a process, (b) a module, or (c) an executable file, so it is technically ambiguous, but it is often the only obvious uniquely identifiable way to choose (a), (b), or (c), and people often also work in projects where the ambiguities are not relevant.
But, as you say, for cases when a.exe could mean 1 of N processes, or 1 of N modules, then alternate selections should be possible, e.g. by process ID, or perhaps a per-process label which is inherited from the target?
It would be great if you could have watch views locked to a specific process (or perhaps more generically an address space). This is important for debugging multi-processes at once. For example, if you are debugging 2 (or more) instances the same process and want to inspect a global variable. Well from which process does the debugger choose to show the variable from ? The user needs to have the ability to choose somehow. Maybe being able to specify the process in a view rule would be better ??
Related, I see you default to not attaching to child processes. Could you please add a checkbox in the targets UI for enabling this. This is pretty important for debugging web browsers - which use multi-process for sandbox isolation.
Thanks.
The text was updated successfully, but these errors were encountered: