From: Andrew Cagney <cagney@gnu.org>
To: Bob Rossi <bob@brasko.net>, Daniel Jacobowitz <drow@mvista.com>
Cc: gdb@sources.redhat.com
Subject: Re: [MI] -file-list-exec-source-files
Date: Tue, 17 Feb 2004 18:22:00 -0000 [thread overview]
Message-ID: <40325BC5.4090403@gnu.org> (raw)
In-Reply-To: <20040216160835.GB3978@white>
> On Mon, Feb 16, 2004 at 10:46:28AM -0500, Daniel Jacobowitz wrote:
>
>> 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?
>> > Also, why should the front ends do it, if it can be done correctly in
>> > one place?
>
>>
>> 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.
>
>
> Yes, please excuse me. I am only interested in returning the fullname to
> the front end. I agree with you, symtab->dirname is only useful
> internally in resolving the fullname.
>
>
>> > 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.
To badly generalize, front ends come in two flavours:
- integrated IDEs such as eclipse where the front end thinks it knows
everything
- lighter weight debugger interfaces (Insight, xxgdb, ...) where,
instead, GDB is relied on for the information
In the latter case a full and correct list of file names is entirely
reasonable. e.g., for a filename tab or filename browser.
> Here there is several points to make.
>
> 1. The front should be able to get the fullname for a single source.
>
> -file-list-exec-source-file currently returns the fullname of the
> currently executing file. Which btw, has already had it's symtab read
> in. This is why symtab->dirname is set, and the fullname is accessible.
>
> An parameter should be added to -file-list-exec-source-file. So it can be
> invoked like "-file-list-exec-source-file foo.c"
> With this new command, the user should get the fullname of a particular
> source file, which means reading in the symtab, or modifying the psymtab
> to have the dirname in it.
As the doco suggests, the command's spec came from knowing that
equivalent functionality was required by Insight (see gdb_listfiles in
that code base).
I think -file-list-exec-source-files should take the wild card (and not
-file-list-exec-source-file) because that is returning a list, its only
a small jump to have it return a qualified list.
Also ...
> 2. The user should be able to get all of the fullnames with
> -file-list-exec-source-files?
>
> Currently, -file-list-exec-source-files, prints all of the "filenames"
> by looping through the symtabs and psymtabs. It knows the fullname to
> most of the symtabs, and none of the psymtabs. So, for some files, it
> prints the filename, along with the fullname, and for others it just
> prints the filename.
>
> If it just lists the "filename" and the front wants the "fullname", it
> can use the "filename" as the parameter to -file-list-exec-source-file,
> which will return the "fullname".
>
> However, if the front end wants all of the fullnames, should we make it
> send N commands to -file-list-exec-source-file, or should
> -file-list-exec-source-files take an optional parameter to force it to
> find all of the fullnames?
(Yes, making a front end do that would be dumb :-)
> Basically, this means, GDB will give you all the "filenames" (keys) of
> the current executable. Then, if you want the "fullname"(value), use the
> "filename"(key) as an argument to -file-list-exec-source-file which will
> return the "fullname"(value).
>
> Hmmm, is this a little to confusing?
... I'd specify the interface such that it is expected to return fully
qualified file names. I don't think anything less than that is useful.
So ... what I think has been identified is the need for a symtab query
that returns a list of the currently known fully qualified source files.
How the symtab chooses to implement that query is a separate problem.
This would of course make the implementation something like:
mi_file_list_exec_source_files (..)
char **source_files = symtab_lookup_source_files (<pattern>);
for all source_files
generate MI output
and likely a first draft based somewhat on existing code.
Andrew
next prev parent reply other threads:[~2004-02-17 18:22 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 [this message]
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
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=40325BC5.4090403@gnu.org \
--to=cagney@gnu.org \
--cc=bob@brasko.net \
--cc=drow@mvista.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