Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Jacobowitz <drow@false.org>
Cc: aristovski@qnx.com, gdb-patches@sources.redhat.com
Subject: Re: [RFC] new substitute path when loading feature
Date: Thu, 15 May 2008 19:30:00 -0000	[thread overview]
Message-ID: <uskwjjt2u.fsf@gnu.org> (raw)
In-Reply-To: <20080515160551.GA24101@caradoc.them.org>

> Date: Thu, 15 May 2008 12:05:51 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>
> 
> On Tue, May 13, 2008 at 03:20:41PM -0400, Daniel Jacobowitz wrote:
> > On Tue, May 13, 2008 at 03:11:22PM -0400, Aleksandar Ristovski wrote:
> > > No, this particular issue is not because of the slashes, but rather
> > > due to IS_ABSOLUTE_PATH returning false on a path like "c:/Temp...".
> > 
> > OK.  I think I "fixed" FILENAME_CMP and not IS_ABSOLUTE_PATH, but it
> > would not be hard to do both.
> > 
> > I'll try to post something tonight.
> 
> Sorry, my existing patch was a mess so I had to rewrite it.  I haven't
> really tested this; it doesn't break a native Linux GDB in any case
> that I consider significant.  See the comments in defs.h and utils.c
> for the details.
> 
> Does this fix the same problem you're working on?  Does anyone see a
> problem with the compromises I made here?  Eli, I'd appreciate your
> opinion.

Well, the patch will certainly work with DOS-ish file names on a Posix
host, but I'm worried about breaking file names that are perfectly
valid on Posix filesystems, but which just happen to use colons and
backslashes.  I agree that a probability of meeting such file names on
Posix platforms is miniscule, but this patch leaves the user no fire
escape whatsoever when she does meet them.

Can we please augment this with some minimal band-aid for when
backslashes and colons are literally used in a file name?  Something
like a user option to disable this feature and use normal Posix
file-name syntax?  I figure this would be enough, since mixing object
files compiled on Posix and Windows platforms should be _really_ rare.

> +/* Compare two filenames.  This version should be used instead of
> +   FILENAME_CMP for filenames from debug information; it recognizes
> +   equivalences from compiling on a DOS filesystem even if the
> +   debugger is running on a POSIX host.  */
> +
> +int
> +gdb_filename_cmp (const char *lhs, const char *rhs)
> +{
> +  for (; *lhs || *rhs; lhs++, rhs++)
> +    {
> +#ifndef HAVE_DOS_BASED_FILE_SYSTEM
> +      /* When debugging on a POSIX host, assume that each filename was
> +	 recorded with a single consistent capitalization during
> +	 compilation.  Source trees are too likely to contain both
> +	 main.c and Main.c.  */
> +      if (*lhs == *rhs)
> +	continue;
> +#else
> +      if (tolower (*lhs) == tolower (*rhs))
> +	continue;
> +#endif
> +
> +      if (*lhs == '/' && *rhs == '\\')
> +	continue;
> +      if (*lhs == '\\' && *rhs == '/')
> +	continue;
> +      return (int) *lhs - (int) *rhs;
> +    }
> +  return 0;
> +}

Will this work if the file name is encoded in UTF-8 or some other
multi-byte encoding, btw?  We do want to support those, don't we?


  parent reply	other threads:[~2008-05-15 18:55 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-13 18:56 Aleksandar Ristovski
2008-05-13 19:00 ` Daniel Jacobowitz
2008-05-13 20:24   ` Aleksandar Ristovski
2008-05-13 21:11     ` Daniel Jacobowitz
2008-05-13 21:18       ` Aleksandar Ristovski
2008-05-13 21:40         ` Daniel Jacobowitz
2008-05-15 17:37           ` Daniel Jacobowitz
2008-05-15 19:29             ` Joel Brobecker
2008-05-15 19:30             ` Eli Zaretskii [this message]
2008-05-15 19:44               ` Daniel Jacobowitz
2008-05-15 22:40                 ` Eli Zaretskii
2008-05-16  0:28                   ` Daniel Jacobowitz
2008-05-16  8:15                     ` Aleksandar Ristovski
2008-05-16  8:19                       ` Aleksandar Ristovski
2008-05-16  8:21                       ` Daniel Jacobowitz
2008-05-16 15:26                         ` Mark Kettenis
2008-05-16 15:27                           ` Eli Zaretskii
2008-05-16 15:27                         ` Aleksandar Ristovski
2008-05-16 15:27                           ` Aleksandar Ristovski
2008-05-16 15:27                           ` Eli Zaretskii
2008-05-16 19:21                             ` Aleksandar Ristovski
2008-05-16 19:35                               ` Eli Zaretskii
2008-05-16 19:22                             ` Aleksandar Ristovski
2008-05-16 15:26                       ` Eli Zaretskii
2008-05-15 20:05               ` Joel Brobecker
2008-05-15 19:35             ` Aleksandar Ristovski
2008-05-17 19:49             ` Vladimir Prus
2008-05-19  4:12               ` Vladimir Prus
2008-05-13 21:12     ` Eli Zaretskii

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=uskwjjt2u.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=aristovski@qnx.com \
    --cc=drow@false.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