Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Per-process Watch Views #354

Open
mistymntncop opened this issue Nov 5, 2024 · 3 comments
Open

[Feature Request] Per-process Watch Views #354

mistymntncop opened this issue Nov 5, 2024 · 3 comments
Labels
Debugger Pertains to the debugger. Feature Request A request for a new feature or improvement.

Comments

@mistymntncop
Copy link

mistymntncop commented Nov 5, 2024

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.

@ryanfleury ryanfleury added Feature Request A request for a new feature or improvement. Debugger Pertains to the debugger. labels Nov 10, 2024
@ryanfleury
Copy link
Collaborator

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).

@mistymntncop
Copy link
Author

Thanks for that Ryan :)

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.

@ryanfleury
Copy link
Collaborator

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Debugger Pertains to the debugger. Feature Request A request for a new feature or improvement.
Projects
None yet
Development

No branches or pull requests

2 participants