This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] fullname attribute for GDB/MI stack frames


I'm responding to two messages here in a futile attempt to cut down the
branching factor.  I can't follow this conversation any more.

On Thu, May 05, 2005 at 12:40:26AM +0300, Eli Zaretskii wrote:
> > Date: Wed, 4 May 2005 17:07:17 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb-patches@sources.redhat.com
> > 
> > The value of those functions if they can not find the file is _nil_.
> 
> No, it's not.  Given enough information, e.g., the leading directories
> and the basename, one can reconstruct the absolute file name even if
> it no longer exists.

All they take as an argument is a single filename.  If it doesn't
exist, how can they add any value to that?

> > realpath() returns ENOENT if you hand it a path that does not exist.
> 
> Does GetFullPathName on Windows fails in similar ways for non-existent
> files?

No, it doesn't look like it does.  However, most of what that function
appears to do is what I would want DJGPP to do - add the current drive
and the current directory.

> In any case, the fact that realpath fails for non-existent files does
> not seem to be documented, and I, for one, would not necessarily
> expect that, as some similar functions and system calls I've met over
> the years on other platforms didn't fail like that.

Can you give me an example?  FYI, realpath in POSIX has this property,
so I don't know what you mean by "not documented".

http://www.opengroup.org/onlinepubs/009695399/functions/realpath.html

[ENOENT]
    A component of file_name does not name an existing file or
    file_name points to an empty string.

canonicalize_file_name is slightly different but still requires the
directory to exist:

     In any of the path components except the last one is missing the
     function returns a NULL pointer.  This is also what is returned if
     the length of the path reaches or exceeds `PATH_MAX' characters.
     In any case `errno' is set accordingly.

Not sure what standard that conforms to.

> > There are five calls to xfullpath in GDB.  One is for debugging use
> > (maint print msymbols).  Two are interested in canonicalizing
> > paths which already meet IS_ABSOLUTE_PATH, for the purposes of
> > comparison.  And the last two are in openp, after successfully opening
> > the file.
> > 
> > There are six calls to gdb_realpath.  One is QNX-specific and I'm not
> > precisely sure what it's for.  Four are used on symtabs for string
> > comparison.  And the last one is in the implementation of xfullpath.
> 
> I don't follow the rationale for enumerating the current uses.  These
> are sufficiently general-purpose functions; even if today they are
> used in certain contexts, tomorrow someone could use them in a
> different context.  We need to think about potential uses even if they
> aren't currently in the sources.

My point was that absolutely none of these users are both valid and
relevant according to the point you were making: i.e. don't open the
file, just do string games with it, and then don't use string
comparison to determine if two files are the same.

> > > If the front end is going to open the file, it doesn't matter.  If it
> > > is going to compare files for equality, it should not use string
> > > comparison, for the reasons I explained in another message.
> > 
> > If it's going to open files, it _does_ matter.  You said that the
> > current directory (and presumably the current drive) are global on this
> > platform.  But the current directory is not stable across time.  If the
> > front end changes the current directory after talking to GDB, suddenly
> > it won't be able to open files.
> 
> In some (hopefully rare) cases, yes.  \abc will remain correct as long
> as you don't change the drive; d:foo and d:./foo will remain correct
> as long as you don't change the cwd on drive d:.  Both changes are
> rare in practice.
> 
> However, similar changes that invalidate file names can happen on Unix
> as well: mounted file systems can be unmounted, symlinks can be
> broken, etc.  When that happens, GDB will no longer be able to open the
> file, even if its name is 100% absolute.

These are changes to the system rather than what is generally seen as a
change to the user environment, even if in the DJGPP environment it's a
piece of global state.  Someone could remove the disk, too.  I'm not
sure of the relevance.

> > Can you give me an example of when canonicalization would be harmful? 
> 
> It's gratuitous, even if the result is correct.  And we don't know how
> to detect when it is correct.

If it's incorrect, it's harmful.  That's what I want an example of.  I
don't agree that it's gratuitous - I think it's vital.

> > The only one I can think of is "the current directory was wrong when we
> > tried to open the file, so we change the current directory and things
> > start working".  This relies on a DJGPP specific property
> 
> ??? What DJGPP specific property?  What I had in mind was the GDB "cd"
> command typed by the user (who presumably knows where to go), not
> something specific to DJGPP.

I was referring to the global CWD, and the front end's perspective. 
The front end changes the current directory, and then it can open this
file GDB told it about a while earlier.  The opposite of the broken
case above.

In any case I think there is no point to continuing this discussion.
In particular you wrote:

> Because of 2 reasons: (1) there's nothing wrong with d:foo, so
> resolving the cwd on drive d: would mean gratuitous DOS-specific code
> in a general-purpose source file, which I try to avoid; and (2) because
> years I spent porting dozens of GNU packages to DJGPP led me to this
> engineering decision which I found to work well in _all_ of the many
> packages I ported.  I'm not going to go back and recollect all of the
> complicated situations and reiterate hundreds of hours of testing and
> debugging, just so that openp and xfullpath will look logically
> perfect to an outsider.

For (1), lrealpath already has Windows-specific code so I don't see why
DOS-specific code is inappropriate; for (2) there's nothing I can
possibly say to that since it's an argument of the form "I know
better than you do".

I have no personal involvement in how GDB works on DJGPP.  I don't know
if DJGPP offers the necessary functionality for any MI-based front end.
So I'm willing to leave the documentation saying that the MI returns
absolute, or fully qualified if you prefer, paths on every system even
if that isn't accurate on DJGPP.  I think it's a quality of
implementation improvement to always fully qualify these paths.  You
think it's evil.  So let's continue to not do it on DJGPP; we already
do it everywhere else.

> Beware: you might break things by this change, since currently
> lrealpath returns file names with backslashes, which is not a good
> idea in a program that came from the Posix world.

GDB already handles pathnames with backslashes.  So does GCC.  So do
the GNU binutils.  Those are the only programs I know of which use
libiberty, and except for GDB they use lrealpath already.  The original
implementation of lrealpath was based on gdb_realpath, FYI.  A Windows
developer did the work to make things work properly when using
GetFullPathName.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]