On Fri, Mar 21, 2003 at 01:55:32AM -0800, Jason Molenda wrote:
Hello Bob,
My approval isn't needed for these patches or anything, I'm just
an interested observer making comments.
On Thu, Mar 20, 2003 at 05:44:54PM -0500, Bob Rossi wrote:
> This change essentially adds the command -file-list-exec-source-file to
> the mi commands.
I don't understand why this command is useful.
A UI can get the filename of the currently-executing source file
easily enough with "stack-list-frames 0 1". The pathname is returned
as it was recorded in the debug info from the compiler - it might
be an absolute path or it might be a relative path.
At a minumum, it is a strong convienence function for the front end to
gdb. It guarentees that the front end is thinking about the same file
that gdb is. The front end needs to know about absolute paths. It cares
nothing about relative paths.
If the path is relative, gdb will interpret that pathname based on
the directory gdb was invoked--which presumably the UI did itself.
Or it will be interpreted relative to any paths added with the
"dir" (CLI) / "environment-directory" (MI) command, which the UI
would have added as well. (or it can get the list of paths with
the environment-directory command without any arguments)
Why does this information have to be provided by gdb?
The best answer probably is, because its been provided for the last
decade ( with annotation 1 and 2 ). I strongly believe that just because
gdb is switching its interface to front ends, doesn't mean it should
take away functionality that was provided before.
However, in my opinion, It doesn't really make sense that each front
that implements an interface to gdb figure out how to do each of the
steps provided above. Especially since gdb is already doing all that
work.
Why repeat the functionality in all of the front ends to gdb?
It would seem that the best solution would be if this command could be
automatically run ( on the front end's request ) every time the source
file or line number changed. Just like annotation 1 or 2.