[sdb] Expose the domain of the stack frames #1411
Conversation
This command returns the domain in which the stack frame is executing Bump protocol version.
This property uses the new CMD_STACK_FRAME_GET_DOMAIN command to retrieve and cache the domain in which the stack frame is executing. Bump the protocol version to match the runtime.
Assert that the property returns the proper domain for the stack frame.
|
The errors reported by the buildbot for this are not related to the change. |
|
Doesn't StackFrame.Thread.Domain expose the same info ? The ThreadMirror object is per-domain. |
|
Ah interesting. I think I was taking the domain from the Thread of the event, and not from the frame.Thread.Domain. That's not super intuitive though, as I thought that for thread.GetFrames(), all frames.Thread would point to thread. I'll check tomorrow. If that works I'll simply add a new Domain property on StackFrame which returns this.Thread.Domain. Thanks for the pointer Zoltan! Jb
|
|
You're right, that won't work. Will look at the patch. |
[sdb] Expose the domain of the stack frames
[sdb] Expose the domain of the stack frames
[sdb] Expose the domain of the stack frames Commit migrated from mono/mono@5644d15
When debugging a multi-domain application, the debugger needs to evaluate expressions and types in the domain specific to the stack frame. This PR implements this functionality.
Previously, contexts for stack frames were using the Thread.Domain property, which is incorrect when a thread is executing code in multiple domains.
This patch is licensed under the MIT/X11 license.