I see this modules event: {"type": "event", "event": "module", "body": {"reason": "new", "module": {"id": "system-supplied DSO at 0x7ffff7fc4000", "name": "system-supplied DSO at 0x7ffff7fc4000", "path": "system-supplied DSO at 0x7ffff7fc4000"}}, "seq": 13} Here the "path" should not be present.
I wonder whether gdb should report target: files here.
Probably objfpy_get_filename should check OBJF_NOT_FILENAME
Objfile.is_file already exists, I guess we didn't change 'filename' due to backward-compat concerns?
https://sourceware.org/pipermail/gdb-patches/2023-July/201106.html
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7b4a5561e4bfc251f35c3bdf14f5a780cd3695a8 commit 7b4a5561e4bfc251f35c3bdf14f5a780cd3695a8 Author: Tom Tromey <tromey@adacore.com> Date: Tue Jul 25 10:55:14 2023 -0600 Don't supply DAP 'path' for non-file shared libraries The DAP 'module' event may include a 'path' component. I noticed that this is supplied even when the module in question does not come from a file. This patch only emits this field when the objfile corresponds to a real file. No test case, because I wasn't sure how to write a portable one. However, it's clear from gdb.log on Linux: {"type": "event", "event": "module", "body": {"reason": "new", "module": {"id": "system-supplied DSO at 0x7ffff7fc4000", "name": "system-supplied DSO at 0x7ffff7fc4000"}}, "seq": 21} Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30676
Fixed.