[Bug dap/30665] DAP Server: Relative paths in stacktrace response

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30665

--- Comment #11 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.