Created attachment 15008 [details] dap logs and main.rs Repro steps: 1. put breakpoint on main::main 2. launch debugger in VSCode 3. breakpoint is hit 4. in breakpoints window we can see 1 extra breakpoint that persists after session is ended Note that this behaviour isn't observed with lldb dap. In the following video I launch lldb first (which works correctly) and then gdb with a mentioned bug (see video https://streamable.com/kf6dyr) Attaching logs from both dap servers and main.rs (rustc -g main.rs)
Also you can see on the video that GDB debug session isn't ended when program finishes, while lldb's does. Should I submit separate bug for this?
The two traces don't seem to be from the same kind of session, because in the gdb trace we see: 10:57:31 AM --> setInstructionBreakpoints {"command":"setInstructionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":4} ... which seems weird anyway, why would it be sending this? However, that's just an oddity, probably not really important. I note lldb isn't claiming "supportsInstructionBreakpoints":true, so that probably explains it... I'm going to guess the bug here is this event: 10:57:31 AM <== breakpoint {"type":"event","event":"breakpoint","body":{"reason":"new","breakpoint":{"id":1,"verified":true,"source":{"name":"main.rs","sourceReference":0,"path":"/home/vmakaev/gdb-test/src/main.rs"},"line":2,"instructionReference":"0x80f7"}},"seq":20} Probably this ought to be suppressed since it is also the response to setFunctionBreakpoints. At the same time, it seems like the client should note that two breakpoints have the same "id" and ignore one.
(In reply to Vladimir Makaev from comment #1) > Also you can see on the video that GDB debug session isn't ended when > program finishes, while lldb's does. Should I submit separate bug for this? Probably best. I didn't really understand what to look for in the video. From the log maybe it's the lack of a terminated event? A separate bug would let us investigate it with a separate patch I suppose.
Created attachment 15009 [details] patch Can you try this patch? This is based on the theory that the "new breakpoint" event is the cause of the problem.
It works! Thanks!
(In reply to Vladimir Makaev from comment #1) > Also you can see on the video that GDB debug session isn't ended when > program finishes, while lldb's does. Should I submit separate bug for this? I filed https://sourceware.org/bugzilla/show_bug.cgi?id=30681
https://sourceware.org/pipermail/gdb-patches/2023-July/201097.html
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8a8a5ccadd18b9f1ecb7943bf56fad29c6f529bc commit 8a8a5ccadd18b9f1ecb7943bf56fad29c6f529bc Author: Tom Tromey <tromey@adacore.com> Date: Mon Jul 24 13:28:58 2023 -0600 Do not send "new breakpoint" event when breakpoint is set When the DAP client sets a breakpoint, gdb currently sends a "new breakpoint" event. However, Vladimir Makaev discovered that this causes VSCode to think there are two breakpoints. This patch changes gdb to suppress the event in this case. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30678
Fixed.