From: "Alain Magloire" <alain@qnx.com>
To: gdb@sources.redhat.com
Subject: Re: [MI] -file-list-exec-source-files
Date: Wed, 18 Feb 2004 14:24:00 -0000 [thread overview]
Message-ID: <200402181424.JAA06208@smtp.ott.qnx.com> (raw)
In-Reply-To: <20040216154628.GA996@nevyn.them.org> from "Daniel Jacobowitz" at Feb 16, 2004 10:46:28 AM
>
> 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.
prev parent reply other threads:[~2004-02-18 14:24 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-13 1:29 Bob Rossi
2004-02-16 1:26 ` Bob Rossi
2004-02-16 1:42 ` Kip Macy
2004-02-16 3:19 ` Bob Rossi
2004-02-16 3:30 ` Daniel Jacobowitz
2004-02-16 3:45 ` Bob Rossi
2004-02-16 3:49 ` Daniel Jacobowitz
2004-02-16 15:33 ` Bob Rossi
2004-02-16 15:46 ` Daniel Jacobowitz
2004-02-16 16:08 ` Bob Rossi
2004-02-17 18:22 ` Andrew Cagney
2004-02-17 19:10 ` Bob Rossi
2004-02-17 19:12 ` Daniel Jacobowitz
2004-02-17 19:30 ` Bob Rossi
2004-02-17 19:33 ` Daniel Jacobowitz
2004-02-23 13:13 ` Bob Rossi
2004-02-23 13:55 ` Daniel Jacobowitz
2004-02-24 4:26 ` Bob Rossi
2004-02-27 6:23 ` Bob Rossi
2004-02-27 15:00 ` Daniel Jacobowitz
2004-02-17 19:47 ` Andrew Cagney
2004-02-17 20:02 ` Bob Rossi
2004-02-17 20:27 ` Andrew Cagney
2004-02-17 21:08 ` Bob Rossi
2004-02-17 21:37 ` Daniel Jacobowitz
2004-02-17 21:58 ` Bob Rossi
2004-02-18 14:24 ` Alain Magloire [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200402181424.JAA06208@smtp.ott.qnx.com \
--to=alain@qnx.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox