Skip to content

Fix several bugs with native GDB DAP#12

Merged
derekparker merged 8 commits into
masterfrom
fix/gdb-evaluate-context
Mar 25, 2026
Merged

Fix several bugs with native GDB DAP#12
derekparker merged 8 commits into
masterfrom
fix/gdb-evaluate-context

Conversation

@derekparker

Copy link
Copy Markdown
Member

Fix an issue around serialization of certain requests where the frameID gets lost due to the go-dap extension thinking the int has its zero value and omitting it.

Rely more heavily on request / response sequencing to ensure we are waiting for and receiving the correct response.

derekparker and others added 8 commits March 24, 2026 13:33
Two bugs caused expression evaluation to fail with GDB's native DAP:

1. Default evaluate context was "repl", which GDB interprets as a GDB
   command rather than a language expression. Changed default to "watch"
   per DAP spec semantics.

2. go-dap's EvaluateArguments uses omitempty on FrameId, which drops
   frameId=0 from the JSON. GDB uses 0-based frame IDs, so this caused
   evaluation in global scope where local variables aren't visible.
   Fixed by building evaluate arguments as raw JSON.

Also fixed FrameID parameter to use *FlexInt (pointer) so we can
distinguish "user sent frameId=0" from "frameId not provided", and
changed lastFrameID sentinel from 0 to -1 since 0 is a valid GDB
frame ID.

Adds regression tests for bare expressions, pointer dereference,
address-of, casts, and register access with GDB backend.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Guide AI models to use valid language expressions (not GDB commands like
/x) in the default watch context, and document how to use repl context
for GDB-specific commands.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
GDB's native DAP distinguishes between stopOnEntry (starti, first
instruction in dynamic linker) and stopAtBeginningOfMainSubprogram
(start, main function). The latter is almost always the desired
behavior, matching what users expect from "stop on entry".

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
MCP clients can make concurrent tool calls, but the DAP connection has a
single reader. Without serialization, concurrent calls race on the
reader and receive each other's responses (e.g., info(threads) gets a
ScopesResponse from a concurrent context call).

Add a sync.Mutex to debuggerSession that each tool handler acquires
before sending DAP requests, preventing interleaved reads.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace single-reader architecture docs with serialized mutex docs
now that concurrent tool calls are properly serialized.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@derekparker derekparker merged commit 422a5a8 into master Mar 25, 2026
1 check passed
@derekparker derekparker deleted the fix/gdb-evaluate-context branch March 25, 2026 19:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant