From: Bob Rossi <bob@brasko.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] fullname attribute for GDB/MI stack frames
Date: Tue, 03 May 2005 21:39:00 -0000 [thread overview]
Message-ID: <20050503213943.GG25356@white> (raw)
In-Reply-To: <01c55025$Blat.v2.4$00e755e0@zahav.net.il>
On Wed, May 04, 2005 at 12:12:48AM +0300, Eli Zaretskii wrote:
> > Date: Tue, 3 May 2005 15:56:50 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: gdb-patches@sources.redhat.com
> >
> > When I originally added the field fullname, I purposely picked that name
> > because I was unsure if the path would always be absolute. However, it
> > was to my understand, that it would always be. Thus, in the manual I
> > put,
> >
> > Synopsis
> > -file-list-exec-source-file
> >
> > List the line number, the current source file, and the absolute path to
> > the current source file for the current executable.
> >
> > I always expected the fullname to be absolute.
>
> As I tried to explain, the Windows file names have a semi-absolute
> form. That form is generally treated like an absolute file name
> because the single most important cause for a program to test a file
> name for being absolute is to decide whether we need to prepend the
> cwd to it; d:foo and \abc certainly don't need that! The fullname
> field uses the machinery that was invented mainly for that purpose, so
> it inherits the same behavior.
OK, I'm going to add the examples d:foo and \abc to the doco. This could
potentially help FE developers understand these odd case's when they
appear. Also, it's important to say that the fullname is not necessarily
absolute, but simply the most precise file name that GDB has.
> > Currently, any front end using the fullname output is expecting the
> > output to be an absolute path to a file. If this is not the case in all
> > circumstances, then the documentation and expections of the FE
> > developers need's to change.
>
> As I explained in my previous messages, there's nothing the FE can do
> but try accessing the file as if it were handed an absolute file name.
> So the FE doesn't need to worry about this and doesn't need to change
> its expectations in any way, because no change in expectations will
> ever succeed in resurrecting the missing information (the drive letter
> in the case of \abc and the current directory on drive d: in the case
> of d:foo).
Agreed.
> > I think it would be helpful if we could discover a case in
> > which GDB would not be able to output an absolute path, but would still
> > think that it has an absolute path. If that case is possible, than the
> > doco needs to be updated and the fullname would consider absolute paths
> > and some other special cases (\abc d:foo). If that case is not
> > possible, then we can consider only absolute paths. Does this sound
> > correct?
>
> I cannot say if this is correct because I cannot figure out what are
> you saying. What does it mean for fullname to consider absolute file
> names and also special cases like \abc? How will it ``consider''
> them?
>
> > The code to look at is source.c:openp. The filename_opened parameter is
> > either
> > - NULL
> > - xfullpath (filename) where filename is potentially any file
> > - xfullpath (current_directory/filename)
> >
> > Does anyone know what xfullpath would do if d:foo or \abc was passed to
> > it?
>
> I already answered that in this thread: it will leave \abc intact, and
> d:foo will be converted into d:./foo. (On Windows, that is, and
> assuming that there's no realpath or canonicalize_file_name in MinGW.)
> So xfullpath does not change anything with these cases on Windows (and
> can't, since the necessary information is missing).
What I was trying to say was, if d:foo and d:./foo will currently return in
the fullpath field, then fullname does not always return absolute paths.
I should document -file-list-exec-source-file to state this. Also, the
regex should match the existing functionality (which does not force
absolute paths).
It was Daniel's initial suggestion to not check for an absolute path. I
suggested we should, since I was under the impreession that the fullname
should always check for an absolute path. As Daniel pointed out since
then, it's probably OK to have the regex check for an absolute path,
since we are sure that the testsuite is always going to display that
property.
As a separate issue, we can discuess if fullname should always return as
an absolute path. For now, I'd like to document and test GDB's current
behavior.
Thanks for clearing things up.
Thanks,
Bob Rossi
next prev parent reply other threads:[~2005-05-03 21:39 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-01 19:13 Dennis Brueni
2005-04-02 9:22 ` Eli Zaretskii
2005-04-30 19:18 ` Daniel Jacobowitz
2005-05-01 2:19 ` Bob Rossi
2005-05-01 18:24 ` Eli Zaretskii
2005-05-01 18:34 ` Bob Rossi
2005-05-01 19:02 ` Daniel Jacobowitz
2005-05-02 0:55 ` Bob Rossi
2005-05-02 0:54 ` Bob Rossi
2005-05-02 0:58 ` Daniel Jacobowitz
2005-05-02 19:30 ` Eli Zaretskii
2005-05-02 19:36 ` Bob Rossi
2005-05-02 19:52 ` Eli Zaretskii
2005-05-02 19:55 ` Daniel Jacobowitz
2005-05-02 20:42 ` Eli Zaretskii
2005-05-02 20:49 ` Daniel Jacobowitz
2005-05-02 21:20 ` Bob Rossi
2005-05-03 3:49 ` Eli Zaretskii
2005-05-03 3:42 ` Eli Zaretskii
2005-05-03 3:46 ` Daniel Jacobowitz
2005-05-03 19:36 ` Eli Zaretskii
2005-05-03 19:49 ` Daniel Jacobowitz
2005-05-03 20:05 ` Bob Rossi
2005-05-03 20:49 ` Eli Zaretskii
2005-05-04 13:34 ` Daniel Jacobowitz
2005-05-04 13:51 ` Bob Rossi
2005-05-04 13:52 ` Daniel Jacobowitz
2005-05-04 17:51 ` Eli Zaretskii
2005-05-04 18:06 ` Bob Rossi
2005-05-04 20:32 ` Eli Zaretskii
2005-05-04 18:05 ` Eli Zaretskii
2005-05-04 18:32 ` Daniel Jacobowitz
2005-05-04 20:53 ` Eli Zaretskii
2005-05-04 21:07 ` Daniel Jacobowitz
2005-05-04 21:42 ` Eli Zaretskii
2005-05-04 22:01 ` Daniel Jacobowitz
2005-05-04 23:42 ` Christopher Faylor
2005-05-05 4:15 ` Eli Zaretskii
2005-05-04 23:40 ` Christopher Faylor
2005-05-05 0:05 ` Bob Rossi
2005-05-05 4:02 ` Eli Zaretskii
2005-05-04 23:37 ` Christopher Faylor
2005-05-05 4:05 ` Eli Zaretskii
2005-05-03 19:57 ` Bob Rossi
2005-05-03 21:15 ` Eli Zaretskii
2005-05-03 21:39 ` Christopher Faylor
2005-05-03 22:24 ` Daniel Jacobowitz
2005-05-03 22:27 ` Christopher Faylor
2005-05-04 2:32 ` Bob Rossi
2005-05-04 3:05 ` Christopher Faylor
2005-05-04 17:42 ` Eli Zaretskii
2005-05-04 4:12 ` Eli Zaretskii
2005-05-04 13:00 ` Daniel Jacobowitz
2005-05-04 4:27 ` Eli Zaretskii
2005-05-04 11:48 ` Bob Rossi
2005-05-04 14:55 ` Christopher Faylor
2005-05-04 15:02 ` Bob Rossi
2005-05-04 17:43 ` Eli Zaretskii
2005-05-04 17:58 ` Christopher Faylor
2005-05-04 18:29 ` Eli Zaretskii
2005-05-04 20:39 ` Eli Zaretskii
2005-05-04 23:34 ` Christopher Faylor
2005-05-05 4:08 ` Eli Zaretskii
2005-05-04 13:45 ` Daniel Jacobowitz
2005-05-04 20:20 ` Eli Zaretskii
2005-05-04 20:30 ` Daniel Jacobowitz
2005-05-04 21:24 ` Eli Zaretskii
2005-05-04 14:52 ` Christopher Faylor
2005-05-04 17:48 ` Eli Zaretskii
2005-05-04 18:03 ` Christopher Faylor
2005-05-04 18:26 ` Eli Zaretskii
2005-05-03 21:39 ` Bob Rossi [this message]
2005-05-03 22:14 ` Christopher Faylor
2005-05-04 4:08 ` Eli Zaretskii
2005-05-04 13:39 ` Daniel Jacobowitz
2005-05-04 17:49 ` Eli Zaretskii
2005-05-04 4:18 ` Eli Zaretskii
2005-05-03 22:50 ` Bob Rossi
2005-05-04 4:04 ` Eli Zaretskii
2005-05-05 17:20 ` Bob Rossi
2005-05-05 18:04 ` Eli Zaretskii
2005-05-05 19:18 ` Christopher Faylor
2005-05-05 23:53 ` Bob Rossi
2005-05-05 16:22 ` Bob Rossi
2005-05-05 16:26 ` Daniel Jacobowitz
2005-05-05 16:46 ` Bob Rossi
2005-05-05 17:17 ` Daniel Jacobowitz
2005-05-18 4:44 ` Daniel Jacobowitz
-- strict thread matches above, loose matches on Subject: below --
2005-05-05 15:15 Dennis Brueni
2005-05-05 15:25 ` Bob Rossi
2005-05-05 15:28 ` Daniel Jacobowitz
2005-05-05 15:32 ` Bob Rossi
2005-05-02 14:22 Dennis Brueni
2005-05-02 19:38 ` Eli Zaretskii
2005-04-01 15:09 Dennis Brueni
2005-03-29 20:43 Dennis Brueni
2005-03-30 4:46 ` Eli Zaretskii
2005-04-01 1:41 ` Bob Rossi
2005-03-26 13:43 Eli Zaretskii
2005-03-26 13:50 ` Bob Rossi
2005-03-24 20:49 Dennis Brueni
2005-03-23 22:22 Dennis Brueni
2005-03-23 22:34 ` Bob Rossi
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=20050503213943.GG25356@white \
--to=bob@brasko.net \
--cc=eliz@gnu.org \
--cc=gdb-patches@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