This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adding -file-list-exec-source-file command to GDB/MI


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.

Bobby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]