Patchwork [libiberty,include] : PR debug/28047 DWARF output_file_names should really understand DOS pathnames

login
register
mail settings
Submitter Kai Tietz
Date Feb. 24, 2011, 9:50 a.m.
Message ID <AANLkTimbV6+pGrwLXpBHAMta0FB1YWjafTeh3Cyd0WCg@mail.gmail.com>
Download mbox | patch
Permalink /patch/84373/
State New
Headers show

Comments

Kai Tietz - Feb. 24, 2011, 9:50 a.m.
Hello,

For this PR (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28047) most
things are already fixed.
Just one point isn't handled correct for DOS-filesystem. As
DOS-filesystem normally uses
case-insensitive path/file-names and backslash/slash as
path-separators, a comparision of
file/path-names via strcmp/strncmp isn't suitable.
I found in libiberty, that there is alread the filename_cmp function,
which handles it proper. As in
source also strncmp is used, I added to libiberty the new function
filename_ncmp, which is for
none-DOS file-systems just the strncmp function, and for DOS-case an
implementation of
strncasecmp with special handling for the path-separators.

ChangeLog gcc/

2011-02-24  Kai Tietz

	PR debug/28047
	* dwarf2out.c (file_table_eq): Use filename_cmp instead of strcmp.
	* dwarf2out.c (lookup_filename): Likewise.
	* final.c (remap_debug_filename): Use filename_ncmp instead of
	strncmp.

ChangeLog /include

2011-02-24  Kai Tietz

	* filenames.h (filename_ncmp): New prototype.

ChangeLog /libiberty

2011-02-24  Kai Tietz

	* filename_cmp.c (filename_ncmp): New function.
	* functions.texi: Regenerated.

Tested for i686-pc-mingw32, x86_64-w64-mingw32, and regression-tested
for x86_64-pc-linux-gnu. Ok for apply?

Regards,
Kai
Jason Merrill - Feb. 24, 2011, 3:46 p.m.
OK (but you'll need to get a release manager to sign off if you want it 
in 4.6, since it isn't a regression).

Jason
Kai Tietz - Feb. 26, 2011, 10:35 a.m.
2011/2/24 Jason Merrill <jason@redhat.com>:
> OK (but you'll need to get a release manager to sign off if you want it in
> 4.6, since it isn't a regression).
>
> Jason
>

Hi Richard,

I would like to get this patch into 4.6. The outstanding issues about
file/path-name comparsion in other places of gcc will be something for
4.7. But I would like to have the libiberty changes in as soon as
possible, as those are of interest for some adjustments in binutils,
too.
So I want to ask if patch is ok for gcc, too?

Regards,
Kai
Richard Guenther - Feb. 26, 2011, 5:50 p.m.
On Sat, Feb 26, 2011 at 11:35 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 2011/2/24 Jason Merrill <jason@redhat.com>:
>> OK (but you'll need to get a release manager to sign off if you want it in
>> 4.6, since it isn't a regression).
>>
>> Jason
>>
>
> Hi Richard,
>
> I would like to get this patch into 4.6. The outstanding issues about
> file/path-name comparsion in other places of gcc will be something for
> 4.7. But I would like to have the libiberty changes in as soon as
> possible, as those are of interest for some adjustments in binutils,
> too.
> So I want to ask if patch is ok for gcc, too?

I cannot comment about the libiberty pieces, those should get review
by a libiberty maintainer which should decide whether they are ok for 4.6.
If Jason is fine with the C++ changes I am, too.

Richard.

> Regards,
> Kai
>
Kai Tietz - Feb. 27, 2011, 10:57 a.m.
2011/2/26 Richard Guenther <richard.guenther@gmail.com>:
> On Sat, Feb 26, 2011 at 11:35 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
>> 2011/2/24 Jason Merrill <jason@redhat.com>:
>>> OK (but you'll need to get a release manager to sign off if you want it in
>>> 4.6, since it isn't a regression).
>>>
>>> Jason
>>>
>>
>> Hi Richard,
>>
>> I would like to get this patch into 4.6. The outstanding issues about
>> file/path-name comparsion in other places of gcc will be something for
>> 4.7. But I would like to have the libiberty changes in as soon as
>> possible, as those are of interest for some adjustments in binutils,
>> too.
>> So I want to ask if patch is ok for gcc, too?
>
> I cannot comment about the libiberty pieces, those should get review
> by a libiberty maintainer which should decide whether they are ok for 4.6.
> If Jason is fine with the C++ changes I am, too.
>
> Richard.
>
>> Regards,
>> Kai
>>
>

Hello DJ,

any comments about the libiberty part of this patch?

Thanks in advance,
Kai
DJ Delorie - Feb. 28, 2011, 4:50 p.m.
The libiberty parts are OK
Kai Tietz - Feb. 28, 2011, 6:37 p.m.
2011/2/28 DJ Delorie <dj@redhat.com>:
>
> The libiberty parts are OK
>

Applied at rev. 170570.

Regards,
Kai

Patch

Index: gcc/gcc/dwarf2out.c
===================================================================
--- gcc.orig/gcc/dwarf2out.c	2011-02-12 19:46:22.000000000 +0100
+++ gcc/gcc/dwarf2out.c	2011-02-24 10:01:08.286708200 +0100
@@ -21560,7 +21560,7 @@  file_table_eq (const void *p1_p, const v
   const struct dwarf_file_data *const p1 =
     (const struct dwarf_file_data *) p1_p;
   const char *const p2 = (const char *) p2_p;
-  return strcmp (p1->filename, p2) == 0;
+  return filename_cmp (p1->filename, p2) == 0;
 }
 
 static hashval_t
@@ -21591,7 +21591,7 @@  lookup_filename (const char *file_name)
      call matches this file name.  If so, return the index.  */
   if (file_table_last_lookup
       && (file_name == file_table_last_lookup->filename
-	  || strcmp (file_table_last_lookup->filename, file_name) == 0))
+	  || filename_cmp (file_table_last_lookup->filename, file_name) == 0))
     return file_table_last_lookup;
 
   /* Didn't match the previous lookup, search the table.  */
Index: gcc/gcc/final.c
===================================================================
--- gcc.orig/gcc/final.c	2011-02-02 08:18:28.000000000 +0100
+++ gcc/gcc/final.c	2011-02-24 09:59:37.412510500 +0100
@@ -1492,7 +1492,7 @@  remap_debug_filename (const char *filena
   size_t name_len;
 
   for (map = debug_prefix_maps; map; map = map->next)
-    if (strncmp (filename, map->old_prefix, map->old_len) == 0)
+    if (filename_ncmp (filename, map->old_prefix, map->old_len) == 0)
       break;
   if (!map)
     return filename;
Index: gcc/include/filenames.h
===================================================================
--- gcc.orig/include/filenames.h	2010-09-09 16:15:02.000000000 +0200
+++ gcc/include/filenames.h	2011-02-24 10:17:55.807335100 +0100
@@ -73,6 +73,9 @@  extern "C" {
 extern int filename_cmp (const char *s1, const char *s2);
 #define FILENAME_CMP(s1, s2)	filename_cmp(s1, s2)
 
+extern int filename_ncmp (const char *s1, const char *s2,
+			  size_t n);
+
 #ifdef __cplusplus
 }
 #endif
Index: gcc/libiberty/filename_cmp.c
===================================================================
--- gcc.orig/libiberty/filename_cmp.c	2010-09-09 16:15:04.000000000 +0200
+++ gcc/libiberty/filename_cmp.c	2011-02-24 10:28:56.891147000 +0100
@@ -76,3 +76,52 @@  filename_cmp (const char *s1, const char
 #endif
 }
 
+/*
+
+@deftypefn Extension int filename_ncmp (const char *@var{s1}, const char *@var{s2}, size_t @var{n})
+
+Return zero if the two file names @var{s1} and @var{s2} are equivalent
+in range @var{n}.
+If not equivalent, the returned value is similar to what @code{strncmp}
+would return.  In other words, it returns a negative value if @var{s1}
+is less than @var{s2}, or a positive value if @var{s2} is greater than
+@var{s2}.
+
+This function does not normalize file names.  As a result, this function
+will treat filenames that are spelled differently as different even in
+the case when the two filenames point to the same underlying file.
+However, it does handle the fact that on DOS-like file systems, forward
+and backward slashes are equal.
+
+@end deftypefn
+
+*/
+
+int
+filename_ncmp (const char *s1, const char *s2, size_t n)
+{
+#ifndef HAVE_DOS_BASED_FILE_SYSTEM
+  return strncmp(s1, s2, n);
+#else
+  if (!n)
+    return 0;
+  for (; n > 0; --n)
+  {
+      int c1 = TOLOWER (*s1);
+      int c2 = TOLOWER (*s2);
+
+      /* On DOS-based file systems, the '/' and the '\' are equivalent.  */
+      if (c1 == '/')
+        c1 = '\\';
+      if (c2 == '/')
+        c2 = '\\';
+
+      if (c1 == '\0' || c1 != c2)
+        return (c1 - c2);
+
+      s1++;
+      s2++;
+  }
+  return 0;
+#endif
+}
Index: gcc/libiberty/functions.texi
===================================================================
--- gcc.orig/libiberty/functions.texi	2011-02-03 21:36:57.000000000 +0100
+++ gcc/libiberty/functions.texi	2011-02-24 10:14:02.136969900 +0100
@@ -296,6 +296,24 @@  and backward slashes are equal.
 
 @end deftypefn
 
+@c filename_cmp.c:81
+@deftypefn Extension int filename_ncmp (const char *@var{s1}, const char *@var{s2}, size_t @var{n})
+
+Return zero if the two file names @var{s1} and @var{s2} are equivalent
+in range @var{n}.
+If not equivalent, the returned value is similar to what @code{strncmp}
+would return.  In other words, it returns a negative value if @var{s1}
+is less than @var{s2}, or a positive value if @var{s2} is greater than
+@var{s2}.
+
+This function does not normalize file names.  As a result, this function
+will treat filenames that are spelled differently as different even in
+the case when the two filenames point to the same underlying file.
+However, it does handle the fact that on DOS-like file systems, forward
+and backward slashes are equal.
+
+@end deftypefn
+
 @c fnmatch.txh:1
 @deftypefn Replacement int fnmatch (const char *@var{pattern}, @
   const char *@var{string}, int @var{flags})