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
Copy file name to clipboardExpand all lines: .github/agents/basicAgent.agent.md
+31-1Lines changed: 31 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ description: Used for general purpose NodeDev development
12
12
13
13
1) You must always read the documentation files when they are related to your current task. They are described in the "Documentation" section of this document.
14
14
2) You must always run the tests and make sure they are passing before you consider your job as completed, no matter how long you have been at the task or any following instruction to make it short or end the task early.
15
-
3) Disabling, removing, skipping, deleting, bypassing or converting to warnings ANY tests IS NOT ALLOWED and is not considered the right way of fixing a problematic test. The test must be functional and actually testing what it is intended to test.
15
+
3)**CRITICAL: Disabling, removing, skipping, deleting, bypassing or converting to warnings ANY tests IS NOT ALLOWED and is not considered the right way of fixing a problematic test. The test must be functional and actually testing what it is intended to test. DO NOT REMOVE TESTS UNLESS EXPLICITLY INSTRUCTED TO DO SO BY THE USER.**
16
16
4) Document newly added content or concepts in this `.github/agents/basicAgent.agent.md` file or any related documentation file.
17
17
5) When the user corrects major mistakes done during your development, document them in this file to ensure it is never done again.
18
18
6) You must always install playwright BEFORE trying to run the tests. build the projects and install playwright. If you struggle (take multiple iterations to do it), document the steps you took in this file to make it easier next time.
@@ -192,11 +192,41 @@ The debugging infrastructure is located in `src/NodeDev.Core/Debugger/` and prov
192
192
-**DebugSessionEngine**: Main debugging engine with process launch, attach, and callback handling
193
193
-**ManagedDebuggerCallbacks**: Implementation of ICorDebugManagedCallback interfaces via ClrDebug
194
194
-**DebugEngineException**: Custom exception type for debugging errors
195
+
-**NodeBreakpointInfo**: Maps nodes to their generated source code locations for breakpoint resolution
196
+
-**BreakpointMappingInfo**: Collection of all breakpoint information for a compiled project
195
197
196
198
**Dependencies:**
197
199
-`ClrDebug` (v0.3.4): C# wrappers for the unmanaged ICorDebug API
198
200
-`Microsoft.Diagnostics.DbgShim` (v9.0.652701): Native dbgshim library for all platforms
199
201
202
+
### Breakpoint System
203
+
NodeDev supports setting breakpoints on nodes during debugging. The system tracks node-to-source-line mappings during compilation:
204
+
205
+
**Infrastructure:**
206
+
1.**Node Marking**: Nodes are marked with `BreakpointDecoration` (only non-inlinable nodes support breakpoints)
207
+
2.**Line Tracking**: `RoslynGraphBuilder.BuildStatementsWithBreakpointTracking()` tracks which source line each node generates
208
+
3.**Compilation**: `RoslynNodeClassCompiler` collects all breakpoint mappings into `BreakpointMappingInfo`
209
+
4.**Storage**: Project stores breakpoint mappings after build for use during debugging
210
+
5.**Debug Engine**: `DebugSessionEngine` receives breakpoint mappings and attempts to set breakpoints after modules load
211
+
212
+
**Implementation:**
213
+
- ✅ Node breakpoint marking and persistence
214
+
- ✅ #line directives with virtual line numbers for stable mapping
215
+
- ✅ PDB sequence point reading for accurate IL offset resolution
216
+
- ✅ Breakpoint mapping storage in compilation results
217
+
- ✅ Debug engine infrastructure for breakpoint management
218
+
- ✅ Actual ICorDebug breakpoint setting with `ICorDebugFunction.CreateBreakpoint()`
219
+
- ✅ Execution pauses at breakpoints and resumes with Continue()
220
+
221
+
**How It Works:**
222
+
1. UI allows toggling breakpoints on nodes (F9 or toolbar button)
223
+
2. Breakpoints persist across save/load
224
+
3. Compilation adds #line directives with virtual line numbers (10000, 11000, 12000...)
225
+
4. PDB sequence points are read to map virtual lines to exact IL offsets
226
+
5. Debug engine creates actual ICorDebug breakpoints at precise locations
227
+
6. Execution pauses when breakpoints are hit
228
+
7. User can resume with Continue()
229
+
200
230
### ScriptRunner
201
231
NodeDev includes a separate console application called **ScriptRunner** that serves as the target process for debugging. This architecture supports "Hard Debugging" via the ICorDebug API.
0 commit comments