Created attachment 14996 [details] Log files and main.rs When debugging with newly added DAP server my VSCode shows me and error "Could not load source 'main.rs': 'source'." The same binary debugged with LLDB DAP works correctly. Most likely the issue is due to some responses from DAP having relative path instead of absolute path Attaching logs from debugging session with gdb and lldb and also a main.rs program. (to compile I used "rustc -g main.rs")
Created attachment 14997 [details] patch Added proposed patch
The gdb log has: 4:38:59 PM <-- stackTrace {"request_seq":11,"type":"response","command":"stackTrace","body":{"stackFrames":[{"id":0,"name":"main::main","line":3,"column":0,"instructionPointerReference":"0x555555408175","source":{"name":"main.rs","path":"main.rs","sourceReference":0}}]},"success":true,"seq":37} ... whereas the lldb log uses "path":"/home/vmakaev/gdb-test/main.rs". gdb also sends this "path" value in other spots, so it seems specific to stack trace.
That patch would work except we recently changed this code to use frame filters. Perhaps FrameDecorator needs to change.
I think it's kind of difficult to write a test for this that can live in-tree, due to how the test suite works. Anyway I have a patch you can try, will upload shortly.
Maybe the testing could be done by also implementing 'cwd' in the launch request, a la https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/issues/90
Created attachment 15006 [details] patch Could you try this patch in your setup?
The "cwd" thing is super wrong because what really matters is passing a relative file name to gcc.
I've updated my remote branch to point to the latest code (I think I had some mirror before which wasn't updated). After applying the patch I confirm the issue is fixed. Thanks for looking into it!
Mine.
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=65403bd0ed22f7c26f972449403c97ff5e998b04 commit 65403bd0ed22f7c26f972449403c97ff5e998b04 Author: Tom Tromey <tromey@adacore.com> Date: Mon Jul 24 08:48:00 2023 -0600 Full paths in DAP stackTrace responses Vladimir Makaev noticed that, in some cases, a DAP stackTrace response would include a relative path name for the "path" component. This patch changes the frame decorator code to add a new DAP-specific decorator, and changes the DAP entry point to frame filters to use it. This decorator prefers the symtab's full name, and does not fall back to the solib's name. I'm not entirely happy with this patch, because if a user frame filter uses FrameDecorator, it may still do the wrong thing. It would be better to have frame filters return symtab-like objects instead, or to have a separate method to return the full path to the source file. I also tend to think that the solib fallback behavior of FrameDecorator is a mistake. If this is ever needed, it seems to me that it should be a separate method. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30665
Fixed.