Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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



  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