-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[mono][debugger] Support debug after hot-reload #55220
Conversation
* origin/main: (27 commits) [mono][llvm] Only emit 'LLVM failed' messages on verbosity > 0. (dotnet#55060) Http2Stream throws a wrapped Http2ConnectionException on GO_AWAY (dotnet#54625) [main] Update dependencies from dnceng/internal/dotnet-optimization dotnet/arcade dotnet/xharness dotnet/hotreload-utils (dotnet#55007) disable a failing test. (dotnet#55063) [mono][wasm] Disable some tests which crash on AOT. (dotnet#55054) Fix fix_allocation_context for regions (dotnet#54931) Delete stale references to System.IO.FileSystem.Primitives (dotnet#55041) Add binplaced analyzers to ASP.NET transport package (dotnet#55042) [mono] Enable many HardwareIntrinsic tests on wasm Delete `compQuirkForPPP`. (dotnet#55050) [Mono] Condition Workload AOT import to be osx only (dotnet#55040) package native quic library (dotnet#54992) Make GlobalizationMode code consistent (dotnet#55039) Expand PerfMap format to support metadata for symbol indexation (dotnet#53792) [debugger]Componentize debugger (dotnet#54887) [Mono] Include loaded interpreter methods as EventPipe session rundown method events. (dotnet#54953) Delete stale ActiveIssue from HttpHeadersTest (dotnet#55027) Poison address-exposed user variables in debug (dotnet#54685) Recategorize emsdk dependency (dotnet#55028) Remove the the wasm AOT specific test project exclusions (dotnet#54988) ...
Tagging subscribers to this area: @thaystg Issue DetailsImplemented the runtime side. To do in another PR, implement support on debugger-libs for Android.
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsImplemented the runtime side. To do in another PR, implement support on debugger-libs for Android.
|
static void | ||
send_enc_delta (MonoImage *image, gconstpointer dmeta_bytes, int32_t dmeta_len, gconstpointer dpdb_bytes, int32_t dpdb_len) | ||
{ | ||
//TODO: if it came from debugger we don't need to pass the parameters back, they are already on debugger client side. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is related to issue #55228 - we can assume that if the debugger is attached, all updates are coming through the debugger command, not through the managed icall.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I cannot change this right now for WASM, am I right?
Because for wasm the updates are not coming through debugger.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's right. I think for wasm the updates are always through dotnet watch
, and not through the debugger.
if (!cols [MONO_METHODBODY_SEQ_POINTS]) | ||
return NULL; | ||
|
||
const char *ptr = mono_metadata_blob_heap (image_dppdb, cols [MONO_METHODBODY_SEQ_POINTS]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little bit surprised this is a heap offset in the delta pdb. For the metadata, the heap offset is in the combined baseline+delta heaps. (ie if originally the blob heap was 1000 bytes and the delta metadata has 500 more bytes, then the metadata tables in the delta will have offsets like 1001-1500, not 1-500.)
But these formats aren't very consistent. So I assume you saw in a testcase that it's always offsets in the delta pdb heap only.
@@ -9775,8 +9775,7 @@ mono_interp_transform_method (InterpMethod *imethod, ThreadContext *context, Mon | |||
|
|||
MonoJitMemoryManager *jit_mm = get_default_jit_mm (); | |||
jit_mm_lock (jit_mm); | |||
if (!g_hash_table_lookup (jit_mm->seq_points, imethod->method)) | |||
g_hash_table_insert (jit_mm->seq_points, imethod->method, imethod->jinfo->seq_points); | |||
g_hash_table_replace (jit_mm->seq_points, imethod->method, imethod->jinfo->seq_points); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we also need to do something in copy_imethod_for_frame
:
In hot reload, the existing version of a method that is already running will finish with the old body, and new calls will use the new method body. So it is possible to hit a breakpoint in an old version of the method. So I think we might need to make a copy of the old seq points in copy_imethod_for_frame
. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure, this seq_points
would only be used to set breakpoint. So it would be possible to be debugging this method with old body?
Like: Thread A is running MethodA and it's stopped in a breakpoint.
In debugger we change something in MethodA so it will replace the MethodA body.
On Thread A we set another breakpoint in another line using the old body and then resume.
Would it be possible to do? While it is stopped in a breakpoint change something and send the deltas to runtime?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like: Thread A is running MethodA and it's stopped in a breakpoint.
In debugger we change something in MethodA so it will replace the MethodA body.
On Thread A we set another breakpoint in another line using the old body and then resume.
I think this is possible. @tmat - VS can show the old and the new body of MethodA? Is that something that is already supported by VS, or something we are considering to do in the future?
src/mono/wasm/debugger/tests/ApplyUpdateReferencedAssembly/MethodBody1_v2.cs
Outdated
Show resolved
Hide resolved
Co-authored-by: Aleksey Kliger (λgeek) <akliger@gmail.com>
/azp run |
You have several pipelines (over 10) configured to build pull requests in this repository. Specify which pipelines you would like to run by using /azp run [pipelines] command. You can specify multiple pipelines using a comma separated list. |
/azp run runtime |
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
To do in another PR, implement support on debugger-libs for Android.