Re: [PATCH 6/7] Use canonicalize_file_name unconditionally

[Joel Brobecker <brobecker@adacore.com>]

Hi Yao,

> > I guess one step at a time, but why not use canonicalize_file_name
> > on Windows hosts as well? My question is not necessarily to suggest
> > that we should be doing it, but rather whether you know of a reason
> > why we should not be doing it...
> 
> The code handling Windows host was added by your patch below
> 
>   [RFA/commit] Improve gdb_realpath for Windows hosts
>   https://sourceware.org/ml/gdb-patches/2011-12/msg00785.html
> 
> in order to handle a weird case that compiler produces some debug
> info where the path has double backslashes.  I am not sure gnulib
> realpath is able to handle such case, so I leave the code for Windows
> host there.

Arf! :-)

canonicalize_file_name does, as far as I can tell, collapse multiple
backslashes, but there is one critical difference between both
functions: GetFullPathName just performs the job mechanically
without checking that the path is at all valid, while
canonicalize_file_name requires the path to exist:

/* Return the canonical absolute name of file NAME.  A canonical name
   does not contain any ".", ".." components nor any repeated file name
   separators ('/') or symlinks.  All components must exist.
   The result is malloc'd.  */

Given how frequent it is for source files to be unavailable,
I would say that it would be useful to preserve the GetFullPathName
behavior for those files as well, and allow users to set breakpoints
without having to worry about how many backslashes GCC has been
using. Or said differently, I agree with your decision :-).

I am taking a note to:

  1. Add an extra comment to this part of the code once you've pushed
     your patch;

  2. Double-check what newer versions of GCC do. At some point, perhaps
     we can declare a minimum GCC version that we fully support and
     then mark this code area for possible removal if it ever starts
     causing extra work.

-- 
Joel