This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [MI] -file-list-exec-source-files
- From: "Alain Magloire" <alain at qnx dot com>
- To: gdb at sources dot redhat dot com
- Date: Wed, 18 Feb 2004 09:24:34 -0500 (EST)
- Subject: Re: [MI] -file-list-exec-source-files
>
> On Mon, Feb 16, 2004 at 10:33:29AM -0500, Bob Rossi wrote:
> > Here is the problem I am trying to solve.
> >
> > Any front end needs to know the absolute path to the source files. From
> > what I can see, there are several ways of finding the absolute path.
> > In some cases, all of this info is needed.
>
> > So, basically, I am making an assumption, if GDB can not find the
> > absolute path to the source file, the front end can not. Is this true?
Not entirely. For example, Eclipse/CDT implements a mapping.
That allow folks to "map" paths to a different value.
> > Also, why should the front ends do it, if it can be done correctly in
> > one place?
>
The source lookup is not done by gdb, when the editor comes highlighting
the line, The IDE has a list of paths it has to search.
It is/was not that important to set gdb's directory sources.
> Then why are you trying to return symtab->dirname at all? Or have I
> misinterpreted you, and you were returning symtab->fullname? I don't
> think symtab->dirname should be exposed in this interface.
>
> > As far as I know, most existing front ends use annotate level 1-2-3 to
> > figure out where the source file is. I just want to simplify this
> > process, so that front ends can easily get the absolute path to the
> > source file without having to run multiple commands, like the CLI.
>
> This sounds like the front end is only ever interested in one source
> file at a time, so that would be a more efficient design than asking
> GDB to provide fullnames for every source file at once.
Agreed, we have folks using the CDT having > 10 000 files, source lookup
is a pain. Having the fullPath is a definitive plus, even if we do
processing like respecting the paths order and mapping.