handling of absolute source file paths

handling of absolute source file paths

[Baurjan Ismagulov]

[-- Attachment #1: Type: text/plain, Size: 1888 bytes --]

Hello,

considering http://sources.redhat.com/gdb/current/onlinedocs/gdb_8.html
, I expect the following behaviour:

$ mkdir /src /tmp/bin /tmp/src
$ cp /bin/ls /tmp/bin/zzz
$ gdb -q
(gdb) file /bin/zzz
/bin/zzz: Datei oder Verzeichnis nicht gefunden.
(gdb) dir /tmp
Source directories searched: /tmp:$cdir:$cwd
(gdb) file /bin/zzz
/bin/zzz: Datei oder Verzeichnis nicht gefunden.
(gdb) 

$ vi /src/a.c
$ gcc -g -o /tmp/bin/a /src/a.c
$ mv /src/a.c /tmp/src
$ gdb -q /tmp/bin/a
(gdb) l main
1       /src/a.c: Datei oder Verzeichnis nicht gefunden.
        in /src/a.c
(gdb) dir /tmp
Source directories searched: /tmp:$cdir:$cwd
(gdb) l main
1       main(){}

However, due to a change discussed in
http://sources.redhat.com/ml/gdb/2004-01/msg00243.html , gdb isn't able
to find the source even after the "directory" command; I consider this
to be a bug. We've implemented the change proposed in
http://sources.redhat.com/ml/gdb/2004-03/msg00026.html . The patched
version behaves the same for binaries, but finds the sources if the
"directory" command was issued.

I've run the test suite on an i386 platform. The only change was for
gdb.cp/annota2.exp from KFAIL to PASS, which is reported to "sometimes
fail unexpectedly" in PR gdb/544.

The patch applies also to the cvs head.

I suggest that it is included for stable and unstable branches. What do
you think?

I consider this patch to be not legally significant. Please inform me if
you need a copyright assignment.

ChangeLog entry:

	* defs.h:
	exec.c (exec_file_attach):
	nto-tdep.c (nto_find_and_open_solib):
	pa64solib.c (pa64_solib_sizeof_symbol_table):
	solib.c (solib_open):
	somsolib.c (som_solib_sizeof_symbol_table):
	source.c (is_regular_file, openp, open_source_file):
	symfile.c (symfile_bfd_open):
	wince.c (upload_to_device): Differentiate between the search for
	binary and source files.

With kind regards,
Baurjan.

[-- Attachment #2: gdb-6.0-ibr-search_in_path-20040310-1302.diff.gz --]
[-- Type: application/x-gunzip, Size: 2937 bytes --]

Re: handling of absolute source file paths

[Eli Zaretskii]

> Date: Tue, 20 Apr 2004 18:48:57 +0300
> From: Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>
> 
> considering http://sources.redhat.com/gdb/current/onlinedocs/gdb_8.html
> , I expect the following behaviour:

Actually, the manual doesn't describe what happens in the specific
case you are talking about: it says

  Each time GDB wants a source file, it tries all the directories in
  the list, in the order they are present in the list, until it finds
  a file with the desired name

Note that it doesn't specify what happens if the file's name starts
with a slash or otherwise has leading directories.  It would be good
to augment the manual with a more explicit description of cases such
as yours.  Would you like to do that?

> However, due to a change discussed in
> http://sources.redhat.com/ml/gdb/2004-01/msg00243.html , gdb isn't able
> to find the source even after the "directory" command; I consider this
> to be a bug. We've implemented the change proposed in
> http://sources.redhat.com/ml/gdb/2004-03/msg00026.html . The patched
> version behaves the same for binaries, but finds the sources if the
> "directory" command was issued.

First, please in the future send patches as plain text, not as
compressed binary attachments; that might help your patches to be
reviewed sooner.

> I suggest that it is included for stable and unstable branches. What do
> you think?

The patch looks good to me, and I think I can approve it (Andrew?).
So, unless someone else objected, it can go in.  However,

> I consider this patch to be not legally significant. Please inform me if
> you need a copyright assignment.

I don't know if you need an assignment for this patch, so I'll let
others to give you a definitive answer.

Thanks!

Re: handling of absolute source file paths

[Baurjan Ismagulov]

Hello, Eli!

This was FAST 8) , thank you!

On Wed, Apr 21, 2004 at 08:51:55AM +0200, Eli Zaretskii wrote:
>   Each time GDB wants a source file, it tries all the directories in
>   the list, in the order they are present in the list, until it finds
>   a file with the desired name
> 
> Note that it doesn't specify what happens if the file's name starts
> with a slash or otherwise has leading directories.  It would be good
> to augment the manual with a more explicit description of cases such
> as yours.  Would you like to do that?

I will try. Actually, I think my case is covered, but more on it
certainly wouldn't hurt. I'm going to give some examples that I've
played with during testing. Another question is whether such kind of
detail is suitable for "Debugging with GDB", which I'd like to see as a
possibly shortest introduction; but I suppose we don't want to start
"GDB reference manual" now ;) .


> First, please in the future send patches as plain text, not as
> compressed binary attachments; that might help your patches to be
> reviewed sooner.

I will. The reason is highly motivating :) . I usually send them
compressed after an incident with a buggy MTA that reformatted my
patch.


> I don't know if you need an assignment for this patch, so I'll let
> others to give you a definitive answer.

Ok. Basically, it's a less-than-15-liner with repeating series, as
described in http://www.gnu.org/prep/maintain_6.html#SEC6 .


Waiting for an answer on both subjects...


With kind regards,
Baurjan.

Re: handling of absolute source file paths

[Baurjan Ismagulov]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

Hello, Eli!

On Wed, Apr 21, 2004 at 08:51:55AM +0200, Eli Zaretskii wrote:
> The patch looks good to me, and I think I can approve it (Andrew?).
> So, unless someone else objected, it can go in.

Ping?

Attached the uncompressed patch for your convenience.

With kind regards,
Baurjan.

[-- Attachment #2: gdb-6.0-ibr-search_in_path-20040310-1302.diff --]
[-- Type: text/plain, Size: 9675 bytes --]

diff -NaurPX /home/ibr/tmp/root/prg/dontdiff.ibr gdb-6.0.orig/gdb/defs.h gdb-6.0/gdb/defs.h
--- gdb-6.0.orig/gdb/defs.h	Tue Jun 10 16:37:03 2003
+++ gdb-6.0/gdb/defs.h	Thu Mar  4 15:13:51 2004
@@ -570,6 +570,9 @@
 
 /* From source.c */
 
+#define OPF_TRY_CWD_FIRST     0x01
+#define OPF_SEARCH_IN_PATH    0x02
+
 extern int openp (const char *, int, const char *, int, int, char **);
 
 extern int source_full_path_of (char *, char **);
diff -NaurPX /home/ibr/tmp/root/prg/dontdiff.ibr gdb-6.0.orig/gdb/exec.c gdb-6.0/gdb/exec.c
--- gdb-6.0.orig/gdb/exec.c	Tue Jan 21 20:43:47 2003
+++ gdb-6.0/gdb/exec.c	Wed Mar 10 10:41:18 2004
@@ -204,7 +204,7 @@
       char *scratch_pathname;
       int scratch_chan;
 
-      scratch_chan = openp (getenv ("PATH"), 1, filename,
+      scratch_chan = openp (getenv ("PATH"), OPF_TRY_CWD_FIRST, filename,
 		   write_files ? O_RDWR | O_BINARY : O_RDONLY | O_BINARY, 0,
 			    &scratch_pathname);
 #if defined(__GO32__) || defined(_WIN32) || defined(__CYGWIN__)
@@ -212,8 +212,9 @@
 	{
 	  char *exename = alloca (strlen (filename) + 5);
 	  strcat (strcpy (exename, filename), ".exe");
-	  scratch_chan = openp (getenv ("PATH"), 1, exename, write_files ?
-	     O_RDWR | O_BINARY : O_RDONLY | O_BINARY, 0, &scratch_pathname);
+	  scratch_chan = openp (getenv ("PATH"), OPF_TRY_CWD_FIRST, exename,
+	     write_files ? O_RDWR | O_BINARY : O_RDONLY | O_BINARY, 0,
+	     &scratch_pathname);
 	}
 #endif
       if (scratch_chan < 0)
diff -NaurPX /home/ibr/tmp/root/prg/dontdiff.ibr gdb-6.0.orig/gdb/nto-tdep.c gdb-6.0/gdb/nto-tdep.c
--- gdb-6.0.orig/gdb/nto-tdep.c	Tue Jun 17 20:30:48 2003
+++ gdb-6.0/gdb/nto-tdep.c	Wed Mar 10 10:46:37 2004
@@ -115,7 +115,7 @@
   sprintf (buf, path_fmt, arch_path, arch_path, arch_path, arch_path,
 	   arch_path);
 
-  return openp (buf, 1, solib, o_flags, 0, temp_pathname);
+  return openp (buf, OPF_TRY_CWD_FIRST, solib, o_flags, 0, temp_pathname);
 }
 
 void
diff -NaurPX /home/ibr/tmp/root/prg/dontdiff.ibr gdb-6.0.orig/gdb/pa64solib.c gdb-6.0/gdb/pa64solib.c
--- gdb-6.0.orig/gdb/pa64solib.c	Sat Jun  7 01:32:59 2003
+++ gdb-6.0/gdb/pa64solib.c	Wed Mar 10 10:47:33 2004
@@ -157,8 +157,8 @@
 
   /* We believe that filename was handed to us by the dynamic linker, and
      is therefore always an absolute path.  */
-  desc = openp (getenv ("PATH"), 1, filename, O_RDONLY | O_BINARY,
-		0, &absolute_name);
+  desc = openp (getenv ("PATH"), OPF_TRY_CWD_FIRST, filename,
+		O_RDONLY | O_BINARY, 0, &absolute_name);
   if (desc < 0)
     {
       perror_with_name (filename);
diff -NaurPX /home/ibr/tmp/root/prg/dontdiff.ibr gdb-6.0.orig/gdb/solib.c gdb-6.0/gdb/solib.c
--- gdb-6.0.orig/gdb/solib.c	Fri Jun 20 14:23:18 2003
+++ gdb-6.0/gdb/solib.c	Wed Mar 10 10:49:12 2004
@@ -156,15 +156,15 @@
   
   /* If not found, search the solib_search_path (if any).  */
   if (found_file < 0 && solib_search_path != NULL)
-    found_file = openp (solib_search_path,
-			1, in_pathname, O_RDONLY, 0, &temp_pathname);
+    found_file = openp (solib_search_path, OPF_TRY_CWD_FIRST,
+			in_pathname, O_RDONLY, 0, &temp_pathname);
   
   /* If not found, next search the solib_search_path (if any) for the basename
      only (ignoring the path).  This is to allow reading solibs from a path
      that differs from the opened path.  */
   if (found_file < 0 && solib_search_path != NULL)
-    found_file = openp (solib_search_path, 
-                        1, lbasename (in_pathname), O_RDONLY, 0,
+    found_file = openp (solib_search_path, OPF_TRY_CWD_FIRST,
+                        lbasename (in_pathname), O_RDONLY, 0,
                         &temp_pathname);
 
   /* If not found, try to use target supplied solib search method */
@@ -175,13 +175,15 @@
   /* If not found, next search the inferior's $PATH environment variable. */
   if (found_file < 0 && solib_absolute_prefix == NULL)
     found_file = openp (get_in_environ (inferior_environ, "PATH"),
-			1, in_pathname, O_RDONLY, 0, &temp_pathname);
+			OPF_TRY_CWD_FIRST, in_pathname, O_RDONLY, 0,
+			&temp_pathname);
 
   /* If not found, next search the inferior's $LD_LIBRARY_PATH 
      environment variable. */
   if (found_file < 0 && solib_absolute_prefix == NULL)
     found_file = openp (get_in_environ (inferior_environ, "LD_LIBRARY_PATH"),
-			1, in_pathname, O_RDONLY, 0, &temp_pathname);
+			OPF_TRY_CWD_FIRST, in_pathname, O_RDONLY, 0,
+			&temp_pathname);
 
   /* Done.  If not found, tough luck.  Return found_file and 
      (optionally) found_pathname.  */
diff -NaurPX /home/ibr/tmp/root/prg/dontdiff.ibr gdb-6.0.orig/gdb/somsolib.c gdb-6.0/gdb/somsolib.c
--- gdb-6.0.orig/gdb/somsolib.c	Tue Mar 18 00:25:08 2003
+++ gdb-6.0/gdb/somsolib.c	Wed Mar 10 10:49:42 2004
@@ -221,7 +221,8 @@
   /* We believe that filename was handed to us by the dynamic linker, and
      is therefore always an absolute path.
    */
-  desc = openp (getenv ("PATH"), 1, filename, O_RDONLY | O_BINARY, 0, &absolute_name);
+  desc = openp (getenv ("PATH"), OPF_TRY_CWD_FIRST, filename,
+		O_RDONLY | O_BINARY, 0, &absolute_name);
   if (desc < 0)
     {
       perror_with_name (filename);
diff -NaurPX /home/ibr/tmp/root/prg/dontdiff.ibr gdb-6.0.orig/gdb/source.c gdb-6.0/gdb/source.c
--- gdb-6.0.orig/gdb/source.c	Wed May 14 19:43:18 2003
+++ gdb-6.0/gdb/source.c	Wed Mar 10 12:57:36 2004
@@ -638,12 +638,18 @@
 /* Open a file named STRING, searching path PATH (dir names sep by some char)
    using mode MODE and protection bits PROT in the calls to open.
 
-   If TRY_CWD_FIRST, try to open ./STRING before searching PATH.
+   OPTS specifies the function behaviour in specific cases.
+
+   If OPF_TRY_CWD_FIRST, try to open ./STRING before searching PATH.
    (ie pretend the first element of PATH is ".").  This also indicates
    that a slash in STRING disables searching of the path (this is
    so that "exec-file ./foo" or "symbol-file ./foo" insures that you
    get that particular version of foo or an error message).
 
+   If OPTS has OPF_SEARCH_IN_PATH set, absolute names will also be
+   searched in path (we usually want this for source files but not for
+   executables).
+
    If FILENAME_OPENED is non-null, set it to a newly allocated string naming
    the actual file opened (this string will always start with a "/").  We
    have to take special pains to avoid doubling the "/" between the directory
@@ -656,7 +662,7 @@
 /*  >>>> This should only allow files of certain types,
     >>>>  eg executable, non-directory */
 int
-openp (const char *path, int try_cwd_first, const char *string,
+openp (const char *path, int opts, const char *string,
        int mode, int prot,
        char **filename_opened)
 {
@@ -674,7 +680,7 @@
   mode |= O_BINARY;
 #endif
 
-  if (try_cwd_first || IS_ABSOLUTE_PATH (string))
+  if ((opts & OPF_TRY_CWD_FIRST) || IS_ABSOLUTE_PATH (string))
     {
       int i;
 
@@ -692,11 +698,16 @@
 	  fd = -1;
 	}
 
-      for (i = 0; string[i]; i++)
-	if (IS_DIR_SEPARATOR (string[i]))
-	  goto done;
+      if (!(opts & OPF_SEARCH_IN_PATH))
+	for (i = 0; string[i]; i++)
+	  if (IS_DIR_SEPARATOR (string[i]))
+	    goto done;
     }
 
+  /* /foo => foo, to avoid multiple slashes that Emacs doesn't like. */
+  while (IS_DIR_SEPARATOR(string[0]))
+    string++;
+
   /* ./foo => foo */
   while (string[0] == '.' && IS_DIR_SEPARATOR (string[1]))
     string += 2;
@@ -796,7 +807,8 @@
 {
   int fd;
 
-  fd = openp (source_path, 1, filename, O_RDONLY, 0, full_pathname);
+  fd = openp (source_path, OPF_TRY_CWD_FIRST | OPF_SEARCH_IN_PATH, filename,
+	      O_RDONLY, 0, full_pathname);
   if (fd < 0)
     {
       *full_pathname = NULL;
@@ -851,13 +863,15 @@
 	}
     }
 
-  result = openp (path, 0, s->filename, OPEN_MODE, 0, &s->fullname);
+  result = openp (path, OPF_SEARCH_IN_PATH, s->filename, OPEN_MODE, 0,
+		  &s->fullname);
   if (result < 0)
     {
       /* Didn't work.  Try using just the basename. */
       p = lbasename (s->filename);
       if (p != s->filename)
-	result = openp (path, 0, p, OPEN_MODE, 0, &s->fullname);
+	result = openp (path, OPF_SEARCH_IN_PATH, p, OPEN_MODE, 0,
+			&s->fullname);
     }
 
   if (result >= 0)
diff -NaurPX /home/ibr/tmp/root/prg/dontdiff.ibr gdb-6.0.orig/gdb/symfile.c gdb-6.0/gdb/symfile.c
--- gdb-6.0.orig/gdb/symfile.c	Thu Aug 14 22:12:31 2003
+++ gdb-6.0/gdb/symfile.c	Wed Mar 10 10:51:32 2004
@@ -1298,14 +1298,15 @@
   name = tilde_expand (name);	/* Returns 1st new malloc'd copy */
 
   /* Look down path for it, allocate 2nd new malloc'd copy.  */
-  desc = openp (getenv ("PATH"), 1, name, O_RDONLY | O_BINARY, 0, &absolute_name);
+  desc = openp (getenv ("PATH"), OPF_TRY_CWD_FIRST, name, O_RDONLY | O_BINARY,
+		0, &absolute_name);
 #if defined(__GO32__) || defined(_WIN32) || defined (__CYGWIN__)
   if (desc < 0)
     {
       char *exename = alloca (strlen (name) + 5);
       strcat (strcpy (exename, name), ".exe");
-      desc = openp (getenv ("PATH"), 1, exename, O_RDONLY | O_BINARY,
-		    0, &absolute_name);
+      desc = openp (getenv ("PATH"), OPF_TRY_CWD_FIRST, exename,
+		    O_RDONLY | O_BINARY, 0, &absolute_name);
     }
 #endif
   if (desc < 0)
diff -NaurPX /home/ibr/tmp/root/prg/dontdiff.ibr gdb-6.0.orig/gdb/wince.c gdb-6.0/gdb/wince.c
--- gdb-6.0.orig/gdb/wince.c	Thu Jun 12 20:01:28 2003
+++ gdb-6.0/gdb/wince.c	Wed Mar 10 10:52:03 2004
@@ -1590,7 +1590,8 @@
     return remotefile;		/* Don't bother uploading. */
 
   /* Open the source. */
-  if ((fd = openp (getenv ("PATH"), TRUE, (char *) from, O_RDONLY, 0, NULL)) < 0)
+  if ((fd = openp (getenv ("PATH"), OPF_TRY_CWD_FIRST, (char *) from, O_RDONLY,
+		   0, NULL)) < 0)
     error ("couldn't open %s", from);
 
   /* Get the time for later comparison. */

Re: handling of absolute source file paths

[Eli Zaretskii]

> Date: Sat, 1 May 2004 19:03:12 +0200
> From: Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>
> 
> Hello, Eli!
> 
> On Wed, Apr 21, 2004 at 08:51:55AM +0200, Eli Zaretskii wrote:
> > The patch looks good to me, and I think I can approve it (Andrew?).
> > So, unless someone else objected, it can go in.
> 
> Ping?

As I already approved this, and no one, including Andrew, neither
objected nor said that I didn't have the powers to approve it, I
guess it can be committed.

Re: handling of absolute source file paths

[Baurjan Ismagulov]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

Hello, Eli!

On Wed, Apr 21, 2004 at 08:51:55AM +0200, Eli Zaretskii wrote:
> Note that it doesn't specify what happens if the file's name starts
> with a slash or otherwise has leading directories.  It would be good
> to augment the manual with a more explicit description of cases such
> as yours.  Would you like to do that?

I've tried to do that. I've removed a paragraph that seemed no longer
relevant. Please review.

	* gdb.texinfo (Specifying source directories): Add an example
	for the 'directory' command.

With kind regards,
Baurjan.

[-- Attachment #2: src-ibr-doc_search-20040501-1848.diff --]
[-- Type: text/plain, Size: 1971 bytes --]

diff -NaurpX /home/ibr/tmp/root/prg/dontdiff.ibr src.orig/gdb/doc/gdb.texinfo src-ibr/gdb/doc/gdb.texinfo
--- src.orig/gdb/doc/gdb.texinfo	Sun Mar 28 14:22:55 2004
+++ src-ibr/gdb/doc/gdb.texinfo	Sat May  1 18:11:44 2004
@@ -4517,16 +4517,21 @@ the directories could be moved between t
 session.  @value{GDBN} has a list of directories to search for source files;
 this is called the @dfn{source path}.  Each time @value{GDBN} wants a source file,
 it tries all the directories in the list, in the order they are present
-in the list, until it finds a file with the desired name.  Note that
-the executable search path is @emph{not} used for this purpose.  Neither is
-the current working directory, unless it happens to be in the source
-path.
+in the list, until it finds a file with the desired name.
 
-If @value{GDBN} cannot find a source file in the source path, and the
-object program records a directory, @value{GDBN} tries that directory
-too.  If the source path is empty, and there is no record of the
-compilation directory, @value{GDBN} looks in the current directory as a
-last resort.
+For example, suppose an executable references the file
+@samp{/usr/src/foo-1.0/lib/foo.c}, and our source path is
+@samp{/mnt/cross}.  The file is first looked up literally; if this
+fails, @samp{/mnt/cross/usr/src/foo-1.0/lib/foo.c} is tried; if this
+fails, @samp{/mnt/cross/foo.c} is opened; if this fails, an error
+message is printed.  The subdirectories of source path directories or
+parts of the source pathname are not looked up.  Plain filenames,
+relative pathnames, pathnames with dots, etc. are all treated as
+described above.
+
+Note that the executable search path is @emph{not} used to locate the
+source files.  Neither is the current working directory, unless it
+happens to be in the source path.
 
 Whenever you reset or rearrange the source path, @value{GDBN} clears out
 any information it has cached about where source files are found and where

Re: handling of absolute source file paths

[Eli Zaretskii]

> Date: Sat, 1 May 2004 19:14:20 +0200
> From: Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>
> 
> On Wed, Apr 21, 2004 at 08:51:55AM +0200, Eli Zaretskii wrote:
> > Note that it doesn't specify what happens if the file's name starts
> > with a slash or otherwise has leading directories.  It would be good
> > to augment the manual with a more explicit description of cases such
> > as yours.  Would you like to do that?
> 
> I've tried to do that.

Thanks.

> I've removed a paragraph that seemed no longer
> relevant. Please review.

A few minor comments, and then the patch can go in:

> +For example, suppose an executable references the file
> +@samp{/usr/src/foo-1.0/lib/foo.c}, and our source path is

First, file names should have the @file markup, not the @samp markup.

>                  The subdirectories of source path directories or
> +parts of the source pathname are not looked up.

Please say "source file name", not "source pathname".  The GNU
project documentation does not use the term ``pathname''.

Also, this specific sentence is not very clear; perhaps an example
using the file names and the source path from your example would help
understand it better.

>  Plain filenames,
> +relative pathnames, pathnames with dots, etc. are all treated as
> +described above.

Please add a ``@:'' after ``etc.'', so that TeX would not typeset
that as an end of a sentence.

Re: handling of absolute source file paths

[Baurjan Ismagulov]

Hello, Eli!

On Sat, May 01, 2004 at 09:11:41PM +0200, Eli Zaretskii wrote:
> First, file names should have the @file markup, not the @samp markup.

Done.


> Please say "source file name", not "source pathname".  The GNU
> project documentation does not use the term ``pathname''.

Done. I just wanted to distinguish a name with a path from a base name.


> Also, this specific sentence is not very clear; perhaps an example
> using the file names and the source path from your example would help
> understand it better.

Tried to do; please review the new variant.


> Please add a ``@:'' after ``etc.'', so that TeX would not typeset
> that as an end of a sentence.

Done.


Here is the ChangeLog entry:

	* gdb.texinfo (Specifying source directories): Add some examples
	for the 'directory' command.


Are you waiting for this one to commit
http://sources.redhat.com/ml/gdb-patches/2004-04/msg00463.html ?


With kind regards,
Baurjan. Attachment:
src-ibr-doc_search-20040508-2304.diff
Description: Text document

Re: handling of absolute source file paths

[Eli Zaretskii]

> Date: Sat, 8 May 2004 23:22:08 +0200
> From: Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>
> 
> > Also, this specific sentence is not very clear; perhaps an example
> > using the file names and the source path from your example would help
> > understand it better.
> 
> Tried to do; please review the new variant.

It's fine, thanks.

There are still a few uses of ``pathname'', though, where ``file
name'' is appropriate:

> +Plain filenames, relative pathnames, pathnames with dots, etc.@: are
> +all treated as described above; for instance, if the source path is

> Are you waiting for this one to commit
> http://sources.redhat.com/ml/gdb-patches/2004-04/msg00463.html ?

Sorry, I can't say right now: can't access that page for some reason.
Will try later.

Re: handling of absolute source file paths

[Baurjan Ismagulov]

Hello, Eli!

On Sun, May 09, 2004 at 08:49:31AM +0200, Eli Zaretskii wrote:
> There are still a few uses of ``pathname'', though, where ``file
> name'' is appropriate:

Ah, sorry, have overlooked. Attached is the corrected version.


> Sorry, I can't say right now: can't access that page for some reason.
> Will try later.

It's http://www.cs.hun.edu.tr/~ibr/gdb-patch-search_in_path.mbox .


With kind regards,
Baurjan. Attachment:
src-ibr-doc_search-20040509-0926.diff
Description: Text document

Re: handling of absolute source file paths

[Eli Zaretskii]

> Date: Sat, 8 May 2004 23:22:08 +0200
> From: Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>
> 
> Here is the ChangeLog entry:
> 
> 	* gdb.texinfo (Specifying source directories): Add some examples
> 	for the 'directory' command.
> 
> 
> Are you waiting for this one to commit
> http://sources.redhat.com/ml/gdb-patches/2004-04/msg00463.html ?

I was trying to approve your patch (all of its parts).  It sounds like
everything is approved now, is that true?

Once approved, it can go in; if you don't have write access to the GDB
CVS tree, I (or someone else) could do that for you.

Andrew, is the paperwork part covered for Baurjan?

Re: handling of absolute source file paths

[Baurjan Ismagulov]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

Hello Eli and Andrew,

On Tue, May 11, 2004 at 07:07:37PM +0200, Eli Zaretskii wrote:
> I was trying to approve your patch (all of its parts).  It sounds like
> everything is approved now, is that true?
> 
> Once approved, it can go in; if you don't have write access to the GDB
> CVS tree, I (or someone else) could do that for you.
> 
> Andrew, is the paperwork part covered for Baurjan?

The paperwork part is completed, here are the patches (they apply
cleanly on HEAD and gdb_6_2-branch). Could anyone please apply that?

With kind regards,
Baurjan.

[-- Attachment #2: gdb-ibr-search_in_path-20040717-1823.diff --]
[-- Type: text/plain, Size: 10343 bytes --]

diff -Naurp -X /home/ibr/tmp/root/prg/dontdiff.ibr src.orig/gdb/defs.h src/gdb/defs.h
--- src.orig/gdb/defs.h	2004-07-17 18:06:35.000000000 +0200
+++ src/gdb/defs.h	2004-07-17 18:22:20.000000000 +0200
@@ -610,6 +610,9 @@ extern void print_address (CORE_ADDR, st
 
 /* From source.c */
 
+#define OPF_TRY_CWD_FIRST     0x01
+#define OPF_SEARCH_IN_PATH    0x02
+
 extern int openp (const char *, int, const char *, int, int, char **);
 
 extern int source_full_path_of (char *, char **);
diff -Naurp -X /home/ibr/tmp/root/prg/dontdiff.ibr src.orig/gdb/exec.c src/gdb/exec.c
--- src.orig/gdb/exec.c	2004-04-24 19:11:14.000000000 +0200
+++ src/gdb/exec.c	2004-07-17 18:22:21.000000000 +0200
@@ -194,7 +194,7 @@ exec_file_attach (char *filename, int fr
       char *scratch_pathname;
       int scratch_chan;
 
-      scratch_chan = openp (getenv ("PATH"), 1, filename,
+      scratch_chan = openp (getenv ("PATH"), OPF_TRY_CWD_FIRST, filename,
 		   write_files ? O_RDWR | O_BINARY : O_RDONLY | O_BINARY, 0,
 			    &scratch_pathname);
 #if defined(__GO32__) || defined(_WIN32) || defined(__CYGWIN__)
@@ -202,8 +202,9 @@ exec_file_attach (char *filename, int fr
 	{
 	  char *exename = alloca (strlen (filename) + 5);
 	  strcat (strcpy (exename, filename), ".exe");
-	  scratch_chan = openp (getenv ("PATH"), 1, exename, write_files ?
-	     O_RDWR | O_BINARY : O_RDONLY | O_BINARY, 0, &scratch_pathname);
+	  scratch_chan = openp (getenv ("PATH"), OPF_TRY_CWD_FIRST, exename,
+	     write_files ? O_RDWR | O_BINARY : O_RDONLY | O_BINARY, 0,
+	     &scratch_pathname);
 	}
 #endif
       if (scratch_chan < 0)
diff -Naurp -X /home/ibr/tmp/root/prg/dontdiff.ibr src.orig/gdb/nto-tdep.c src/gdb/nto-tdep.c
--- src.orig/gdb/nto-tdep.c	2004-04-24 19:11:15.000000000 +0200
+++ src/gdb/nto-tdep.c	2004-07-17 18:22:21.000000000 +0200
@@ -115,7 +115,7 @@ nto_find_and_open_solib (char *solib, un
   sprintf (buf, path_fmt, arch_path, arch_path, arch_path, arch_path,
 	   arch_path);
 
-  return openp (buf, 1, solib, o_flags, 0, temp_pathname);
+  return openp (buf, OPF_TRY_CWD_FIRST, solib, o_flags, 0, temp_pathname);
 }
 
 void
diff -Naurp -X /home/ibr/tmp/root/prg/dontdiff.ibr src.orig/gdb/pa64solib.c src/gdb/pa64solib.c
--- src.orig/gdb/pa64solib.c	2004-05-08 21:02:29.000000000 +0200
+++ src/gdb/pa64solib.c	2004-07-17 18:22:21.000000000 +0200
@@ -157,8 +157,8 @@ pa64_solib_sizeof_symbol_table (char *fi
 
   /* We believe that filename was handed to us by the dynamic linker, and
      is therefore always an absolute path.  */
-  desc = openp (getenv ("PATH"), 1, filename, O_RDONLY | O_BINARY,
-		0, &absolute_name);
+  desc = openp (getenv ("PATH"), OPF_TRY_CWD_FIRST, filename,
+		O_RDONLY | O_BINARY, 0, &absolute_name);
   if (desc < 0)
     {
       perror_with_name (filename);
diff -Naurp -X /home/ibr/tmp/root/prg/dontdiff.ibr src.orig/gdb/solib.c src/gdb/solib.c
--- src.orig/gdb/solib.c	2004-03-11 18:04:40.000000000 +0100
+++ src/gdb/solib.c	2004-07-17 18:22:21.000000000 +0200
@@ -156,15 +156,15 @@ solib_open (char *in_pathname, char **fo
   
   /* If not found, search the solib_search_path (if any).  */
   if (found_file < 0 && solib_search_path != NULL)
-    found_file = openp (solib_search_path,
-			1, in_pathname, O_RDONLY, 0, &temp_pathname);
+    found_file = openp (solib_search_path, OPF_TRY_CWD_FIRST,
+			in_pathname, O_RDONLY, 0, &temp_pathname);
   
   /* If not found, next search the solib_search_path (if any) for the basename
      only (ignoring the path).  This is to allow reading solibs from a path
      that differs from the opened path.  */
   if (found_file < 0 && solib_search_path != NULL)
-    found_file = openp (solib_search_path, 
-                        1, lbasename (in_pathname), O_RDONLY, 0,
+    found_file = openp (solib_search_path, OPF_TRY_CWD_FIRST,
+                        lbasename (in_pathname), O_RDONLY, 0,
                         &temp_pathname);
 
   /* If not found, try to use target supplied solib search method */
@@ -175,13 +175,15 @@ solib_open (char *in_pathname, char **fo
   /* If not found, next search the inferior's $PATH environment variable. */
   if (found_file < 0 && solib_absolute_prefix == NULL)
     found_file = openp (get_in_environ (inferior_environ, "PATH"),
-			1, in_pathname, O_RDONLY, 0, &temp_pathname);
+			OPF_TRY_CWD_FIRST, in_pathname, O_RDONLY, 0,
+			&temp_pathname);
 
   /* If not found, next search the inferior's $LD_LIBRARY_PATH 
      environment variable. */
   if (found_file < 0 && solib_absolute_prefix == NULL)
     found_file = openp (get_in_environ (inferior_environ, "LD_LIBRARY_PATH"),
-			1, in_pathname, O_RDONLY, 0, &temp_pathname);
+			OPF_TRY_CWD_FIRST, in_pathname, O_RDONLY, 0,
+			&temp_pathname);
 
   /* Done.  If not found, tough luck.  Return found_file and 
      (optionally) found_pathname.  */
diff -Naurp -X /home/ibr/tmp/root/prg/dontdiff.ibr src.orig/gdb/somsolib.c src/gdb/somsolib.c
--- src.orig/gdb/somsolib.c	2004-05-19 20:08:14.000000000 +0200
+++ src/gdb/somsolib.c	2004-07-17 18:22:21.000000000 +0200
@@ -216,7 +216,8 @@ som_solib_sizeof_symbol_table (char *fil
   /* We believe that filename was handed to us by the dynamic linker, and
      is therefore always an absolute path.
    */
-  desc = openp (getenv ("PATH"), 1, filename, O_RDONLY | O_BINARY, 0, &absolute_name);
+  desc = openp (getenv ("PATH"), OPF_TRY_CWD_FIRST, filename,
+		O_RDONLY | O_BINARY, 0, &absolute_name);
   if (desc < 0)
     {
       perror_with_name (filename);
diff -Naurp -X /home/ibr/tmp/root/prg/dontdiff.ibr src.orig/gdb/source.c src/gdb/source.c
--- src.orig/gdb/source.c	2004-06-27 22:33:07.000000000 +0200
+++ src/gdb/source.c	2004-07-17 18:23:23.000000000 +0200
@@ -636,12 +636,18 @@ is_regular_file (const char *name)
 /* Open a file named STRING, searching path PATH (dir names sep by some char)
    using mode MODE and protection bits PROT in the calls to open.
 
-   If TRY_CWD_FIRST, try to open ./STRING before searching PATH.
+   OPTS specifies the function behaviour in specific cases.
+
+   If OPF_TRY_CWD_FIRST, try to open ./STRING before searching PATH.
    (ie pretend the first element of PATH is ".").  This also indicates
    that a slash in STRING disables searching of the path (this is
    so that "exec-file ./foo" or "symbol-file ./foo" insures that you
    get that particular version of foo or an error message).
 
+   If OPTS has OPF_SEARCH_IN_PATH set, absolute names will also be
+   searched in path (we usually want this for source files but not for
+   executables).
+
    If FILENAME_OPENED is non-null, set it to a newly allocated string naming
    the actual file opened (this string will always start with a "/").  We
    have to take special pains to avoid doubling the "/" between the directory
@@ -654,7 +660,7 @@ is_regular_file (const char *name)
 /*  >>>> This should only allow files of certain types,
     >>>>  eg executable, non-directory */
 int
-openp (const char *path, int try_cwd_first, const char *string,
+openp (const char *path, int opts, const char *string,
        int mode, int prot,
        char **filename_opened)
 {
@@ -672,7 +678,7 @@ openp (const char *path, int try_cwd_fir
   mode |= O_BINARY;
 #endif
 
-  if (try_cwd_first || IS_ABSOLUTE_PATH (string))
+  if ((opts & OPF_TRY_CWD_FIRST) || IS_ABSOLUTE_PATH (string))
     {
       int i;
 
@@ -690,11 +696,16 @@ openp (const char *path, int try_cwd_fir
 	  fd = -1;
 	}
 
-      for (i = 0; string[i]; i++)
-	if (IS_DIR_SEPARATOR (string[i]))
-	  goto done;
+      if (!(opts & OPF_SEARCH_IN_PATH))
+	for (i = 0; string[i]; i++)
+	  if (IS_DIR_SEPARATOR (string[i]))
+	    goto done;
     }
 
+  /* /foo => foo, to avoid multiple slashes that Emacs doesn't like. */
+  while (IS_DIR_SEPARATOR(string[0]))
+    string++;
+
   /* ./foo => foo */
   while (string[0] == '.' && IS_DIR_SEPARATOR (string[1]))
     string += 2;
@@ -793,7 +804,8 @@ source_full_path_of (char *filename, cha
 {
   int fd;
 
-  fd = openp (source_path, 1, filename, O_RDONLY, 0, full_pathname);
+  fd = openp (source_path, OPF_TRY_CWD_FIRST | OPF_SEARCH_IN_PATH, filename,
+	      O_RDONLY, 0, full_pathname);
   if (fd < 0)
     {
       *full_pathname = NULL;
@@ -864,13 +876,13 @@ find_and_open_source (struct objfile *ob
 	}
     }
 
-  result = openp (path, 0, filename, OPEN_MODE, 0, fullname);
+  result = openp (path, OPF_SEARCH_IN_PATH, filename, OPEN_MODE, 0, fullname);
   if (result < 0)
     {
       /* Didn't work.  Try using just the basename. */
       p = lbasename (filename);
       if (p != filename)
-	result = openp (path, 0, p, OPEN_MODE, 0, fullname);
+	result = openp (path, OPF_SEARCH_IN_PATH, p, OPEN_MODE, 0, fullname);
     }
 
   if (result >= 0)
diff -Naurp -X /home/ibr/tmp/root/prg/dontdiff.ibr src.orig/gdb/symfile.c src/gdb/symfile.c
--- src.orig/gdb/symfile.c	2004-07-15 23:58:03.000000000 +0200
+++ src/gdb/symfile.c	2004-07-17 18:22:21.000000000 +0200
@@ -1221,14 +1221,15 @@ symfile_bfd_open (char *name)
   name = tilde_expand (name);	/* Returns 1st new malloc'd copy */
 
   /* Look down path for it, allocate 2nd new malloc'd copy.  */
-  desc = openp (getenv ("PATH"), 1, name, O_RDONLY | O_BINARY, 0, &absolute_name);
+  desc = openp (getenv ("PATH"), OPF_TRY_CWD_FIRST, name, O_RDONLY | O_BINARY,
+		0, &absolute_name);
 #if defined(__GO32__) || defined(_WIN32) || defined (__CYGWIN__)
   if (desc < 0)
     {
       char *exename = alloca (strlen (name) + 5);
       strcat (strcpy (exename, name), ".exe");
-      desc = openp (getenv ("PATH"), 1, exename, O_RDONLY | O_BINARY,
-		    0, &absolute_name);
+      desc = openp (getenv ("PATH"), OPF_TRY_CWD_FIRST, exename,
+		    O_RDONLY | O_BINARY, 0, &absolute_name);
     }
 #endif
   if (desc < 0)
diff -Naurp -X /home/ibr/tmp/root/prg/dontdiff.ibr src.orig/gdb/wince.c src/gdb/wince.c
--- src.orig/gdb/wince.c	2004-06-25 22:11:54.000000000 +0200
+++ src/gdb/wince.c	2004-07-17 18:22:21.000000000 +0200
@@ -1586,7 +1586,8 @@ upload_to_device (const char *to, const 
     return remotefile;		/* Don't bother uploading. */
 
   /* Open the source. */
-  if ((fd = openp (getenv ("PATH"), TRUE, (char *) from, O_RDONLY, 0, NULL)) < 0)
+  if ((fd = openp (getenv ("PATH"), OPF_TRY_CWD_FIRST, (char *) from, O_RDONLY,
+		   0, NULL)) < 0)
     error ("couldn't open %s", from);
 
   /* Get the time for later comparison. */

[-- Attachment #3: gdb-ibr-doc_search-20040509-0926.diff --]
[-- Type: text/plain, Size: 2497 bytes --]

diff -Naurp -X /home/ibr/tmp/root/prg/dontdiff.ibr src.orig/gdb/doc/gdb.texinfo src-ibr/gdb/doc/gdb.texinfo
--- src.orig/gdb/doc/gdb.texinfo	Sat May  8 21:02:30 2004
+++ src-ibr/gdb/doc/gdb.texinfo	Sun May  9 09:26:23 2004
@@ -4517,16 +4517,30 @@ the directories could be moved between t
 session.  @value{GDBN} has a list of directories to search for source files;
 this is called the @dfn{source path}.  Each time @value{GDBN} wants a source file,
 it tries all the directories in the list, in the order they are present
-in the list, until it finds a file with the desired name.  Note that
-the executable search path is @emph{not} used for this purpose.  Neither is
-the current working directory, unless it happens to be in the source
-path.
+in the list, until it finds a file with the desired name.
 
-If @value{GDBN} cannot find a source file in the source path, and the
-object program records a directory, @value{GDBN} tries that directory
-too.  If the source path is empty, and there is no record of the
-compilation directory, @value{GDBN} looks in the current directory as a
-last resort.
+For example, suppose an executable references the file
+@file{/usr/src/foo-1.0/lib/foo.c}, and our source path is
+@file{/mnt/cross}.  The file is first looked up literally; if this
+fails, @file{/mnt/cross/usr/src/foo-1.0/lib/foo.c} is tried; if this
+fails, @file{/mnt/cross/foo.c} is opened; if this fails, an error
+message is printed.  @value{GDBN} does not look up the parts of the
+source file name, such as @file{/mnt/cross/src/foo-1.0/lib/foo.c}.
+Likewise, the subdirectories of the source path are not searched: if
+the source path is @file{/mnt/cross}, and the binary refers to
+@file{foo.c}, @value{GDBN} would not find it under
+@file{/mnt/cross/usr/src/foo-1.0/lib}.
+
+Plain file names, relative file names with leading directories, file
+names containing dots, etc.@: are all treated as described above; for
+instance, if the source path is @file{/mnt/cross}, and the source file
+is recorded as @file{../lib/foo.c}, @value{GDBN} would first try
+@file{../lib/foo.c}, then @file{/mnt/cross/../lib/foo.c}, and after
+that---@file{/mnt/cross/foo.c}.
+
+Note that the executable search path is @emph{not} used to locate the
+source files.  Neither is the current working directory, unless it
+happens to be in the source path.
 
 Whenever you reset or rearrange the source path, @value{GDBN} clears out
 any information it has cached about where source files are found and where

ping: Re: handling of absolute source file paths

[Baurjan Ismagulov]

On Sat, Jul 17, 2004 at 08:22:28PM +0200, Baurjan Ismagulov wrote:
> The paperwork part is completed, here are the patches (they apply
> cleanly on HEAD and gdb_6_2-branch). Could anyone please apply that?

Eli?

With kind regards,
Baurjan.

	* defs.h:
	exec.c (exec_file_attach):
	nto-tdep.c (nto_find_and_open_solib):
	pa64solib.c (pa64_solib_sizeof_symbol_table):
	solib.c (solib_open):
	somsolib.c (som_solib_sizeof_symbol_table):
	source.c (is_regular_file, openp, open_source_file):
	symfile.c (symfile_bfd_open):
	wince.c (upload_to_device): Differentiate between the search for
	binary and source files.

Re: ping: Re: handling of absolute source file paths

[Eli Zaretskii]

> Date: Fri, 23 Jul 2004 21:58:20 +0200
> From: Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>
> 
> On Sat, Jul 17, 2004 at 08:22:28PM +0200, Baurjan Ismagulov wrote:
> > The paperwork part is completed, here are the patches (they apply
> > cleanly on HEAD and gdb_6_2-branch). Could anyone please apply that?
> 
> Eli?

I asked Andrew for a go-ahead (several days ago, when you first posted
the patch), and am waiting for him to reply.

Re: ping: Re: handling of absolute source file paths

[Andrew Cagney]

>>> Date: Fri, 23 Jul 2004 21:58:20 +0200
>>> From: Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>
>>> 
>>> On Sat, Jul 17, 2004 at 08:22:28PM +0200, Baurjan Ismagulov wrote:
>>
>>>> > The paperwork part is completed, here are the patches (they apply
>>>> > cleanly on HEAD and gdb_6_2-branch). Could anyone please apply that?
>>
>>> 
>>> Eli?
> 
> 
> I asked Andrew for a go-ahead (several days ago, when you first posted
> the patch), and am waiting for him to reply.

I did (last wednesday :-):

 > For now, just to mainline, think about 6.2 branch after 6.2 is out.

Andrew

PS: It's probably best to keep such questions on list.

Re: ping: Re: handling of absolute source file paths

[Baurjan Ismagulov]

Hello Andrew,

On Mon, Jul 26, 2004 at 10:57:24AM -0400, Andrew Cagney wrote:
> >>>>> Could anyone please apply that?
> >>>Eli?
> >I asked Andrew for a go-ahead (several days ago, when you first posted
> >the patch), and am waiting for him to reply.
> 
> I did (last wednesday :-):

Hmm, I don't see the changes in, e.g., source.c 1.53. Are we talking
about the same patch?


> > For now, just to mainline, think about 6.2 branch after 6.2 is out.

What is the reason for that (just to understand how such matters are
handled)?


With kind regards,
Baurjan.

Re: ping: Re: handling of absolute source file paths

[Eli Zaretskii]

> Date: Mon, 26 Jul 2004 18:20:52 +0300
> From: Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>
> > 
> > I did (last wednesday :-):
> 
> Hmm, I don't see the changes in, e.g., source.c 1.53.

That's because I didn't commit them yet.

Re: ping: Re: handling of absolute source file paths

[Andrew Cagney]

>>>For now, just to mainline, think about 6.2 branch after 6.2 is out.
> 
> 
> What is the reason for that (just to understand how such matters are
> handled)?

The emphasis is on getting changes into the mainline for the next 
release (and it is now very very late in the 6.2 release cycle).

For reference:

> @section Branch Commit Policy
> 
> The branch commit policy is pretty slack.  @value{GDBN} releases 5.0,
> 5.1 and 5.2 all used the below:
> 
> @itemize @bullet
> @item
> The @file{gdb/MAINTAINERS} file still holds.
> @item
> Don't fix something on the branch unless/until it is also fixed in the
> trunk.  If this isn't possible, mentioning it in the @file{gdb/PROBLEMS}
> file is better than committing a hack.
> @item
> When considering a patch for the branch, suggested criteria include:
> Does it fix a build?  Does it fix the sequence @kbd{break main; run}
> when debugging a static binary?
> @item
> The further a change is from the core of @value{GDBN}, the less likely
> the change will worry anyone (e.g., target specific code).
> @item
> Only post a proposal to change the core of @value{GDBN} after you've
> sent individual bribes to all the people listed in the
> @file{MAINTAINERS} file @t{;-)}
> @end itemize
> 
> @emph{Pragmatics: Provided updates are restricted to non-core
> functionality there is little chance that a broken change will be fatal.
> This means that changes such as adding a new architectures or (within
> reason) support for a new host are considered acceptable.}

Andrew

Re: ping: Re: handling of absolute source file paths

[Eli Zaretskii]

> Date: Mon, 26 Jul 2004 10:57:24 -0400
> From: Andrew Cagney <cagney@gnu.org>
> > 
> > I asked Andrew for a go-ahead (several days ago, when you first posted
> > the patch), and am waiting for him to reply.
> 
> I did (last wednesday :-):
> 
>  > For now, just to mainline, think about 6.2 branch after 6.2 is out.

Sorry, I misunderstood that.  I will commit the changes as soon as I
have time.

Re: handling of absolute source file paths

[Eli Zaretskii]

> Date: Sat, 17 Jul 2004 20:22:28 +0200
> From: Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>
> 
> The paperwork part is completed, here are the patches (they apply
> cleanly on HEAD and gdb_6_2-branch). Could anyone please apply that?

Done for HEAD.

Re: handling of absolute source file paths

[Baurjan Ismagulov]

On Fri, Jul 30, 2004 at 10:17:40PM +0300, Eli Zaretskii wrote:
> Done for HEAD.

Thank you!

What about 6.2?

With kind regards,
Baurjan.

Re: handling of absolute source file paths

[Eli Zaretskii]

> Date: Sat, 31 Jul 2004 09:59:47 +0200
> From: Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>
> 
> What about 6.2?

I think ANdrew said ``not yet''.

Re: handling of absolute source file paths

[Andrew Cagney]

>>Date: Sat, 31 Jul 2004 09:59:47 +0200
>>> From: Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>
>>> 
>>> What about 6.2?
> 
> 
> I think ANdrew said ``not yet''.

6.2's out and the branch is unfrozen.  So if it's fixing a bug, m'kay.

Andrew

Re: handling of absolute source file paths

[Baurjan Ismagulov]

On Sun, Aug 01, 2004 at 03:30:57PM -0400, Andrew Cagney wrote:
> 6.2's out and the branch is unfrozen.  So if it's fixing a bug, m'kay.

Thanks for the explanation, it is a bugfix. Eli, could you please apply?

With kind regards,
Baurjan.

Re: handling of absolute source file paths

[Eli Zaretskii]

> Date: Tue, 3 Aug 2004 19:02:21 +0200
> From: Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>
> 
> Thanks for the explanation, it is a bugfix. Eli, could you please apply?

Will do when I have time (which I haven't too much of lately), unless
someone beats me to it.

Re: handling of absolute source file paths

[Baurjan Ismagulov]

On Tue, Aug 03, 2004 at 10:10:30PM +0300, Eli Zaretskii wrote:
> Will do when I have time (which I haven't too much of lately)...

No problem, I just wanted to ensure that someone is going to do that.

With kind regards,
Baurjan.