[RFC] make handling of input path vs subfile path consistent

[RFC] make handling of input path vs subfile path consistent

[Doug Evans]

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

Hi.  There's something I don't understand.  Why does start_subfile not
prepend dirname to name if the latter is not absolute?  Since
name,dirname are added to the subfile list if there isn't a match and
then will later be used to do matches, it seems like we want to
prepend dirname to the input name before doing FILENAME_CMP.

Am I missing something?

[-- Attachment #2: gdb-080105-start-subfile-1.patch --]
[-- Type: application/octet-stream, Size: 2032 bytes --]

2008-01-05  Doug Evans  <dje@google.com>

	* buildsym.c (start_subfile): Treat input name like subfile->name,
	prepend their compilation directory when they're relative paths.

Index: buildsym.c
===================================================================
RCS file: /cvs/src/src/gdb/buildsym.c,v
retrieving revision 1.59
diff -u -p -u -p -r1.59 buildsym.c
--- buildsym.c	1 Jan 2008 22:53:09 -0000	1.59
+++ buildsym.c	5 Jan 2008 21:34:33 -0000
@@ -583,35 +583,41 @@ void
 start_subfile (char *name, char *dirname)
 {
   struct subfile *subfile;
+  char *comparable_name = name;
+
+  if (! IS_ABSOLUTE_PATH (name)
+      && dirname != NULL)
+    comparable_name = concat (dirname, SLASH_STRING, name, NULL);
 
   /* See if this subfile is already known as a subfile of the current
      main source file.  */
 
   for (subfile = subfiles; subfile; subfile = subfile->next)
     {
-      char *subfile_name;
+      char *subfile_name = subfile->name;
 
-      /* If NAME is an absolute path, and this subfile is not, then
-	 attempt to create an absolute path to compare.  */
-      if (IS_ABSOLUTE_PATH (name)
-	  && !IS_ABSOLUTE_PATH (subfile->name)
+      /* Combine subfile's name, dirname before comparing.  */
+      if (! IS_ABSOLUTE_PATH (subfile->name)
 	  && subfile->dirname != NULL)
 	subfile_name = concat (subfile->dirname, SLASH_STRING,
 			       subfile->name, NULL);
-      else
-	subfile_name = subfile->name;
 
-      if (FILENAME_CMP (subfile_name, name) == 0)
+      if (FILENAME_CMP (subfile_name, comparable_name) == 0)
 	{
 	  current_subfile = subfile;
 	  if (subfile_name != subfile->name)
 	    xfree (subfile_name);
+	  if (comparable_name != name)
+	    xfree (comparable_name);
 	  return;
 	}
       if (subfile_name != subfile->name)
 	xfree (subfile_name);
     }
 
+  if (comparable_name != name)
+    xfree (comparable_name);
+
   /* This subfile is not known.  Add an entry for it. Make an entry
      for this subfile in the list of all subfiles of the current main
      source file.  */

Re: [RFC] make handling of input path vs subfile path consistent

[Daniel Jacobowitz]

On Sat, Jan 05, 2008 at 02:32:57PM -0800, Doug Evans wrote:
> Hi.  There's something I don't understand.  Why does start_subfile not
> prepend dirname to name if the latter is not absolute?  Since
> name,dirname are added to the subfile list if there isn't a match and
> then will later be used to do matches, it seems like we want to
> prepend dirname to the input name before doing FILENAME_CMP.
> 
> Am I missing something?

I could only come up with one case to worry about: what if
subfile->dirname plus subfile->name produces a relative path that
would previously have matched the NAME argument?  But dwarf2read.c
always passes the compilation directory (which we assume to be an
absolute path) as the dirname argument, so presumably the result of
combining subfile->dirname and subfile->name will be an absolute path
too.

Your patch is OK.

-- 
Daniel Jacobowitz
CodeSourcery

RE: [RFC] make handling of input path vs subfile path consistent

[Aleksandar Ristovski]

> 
> Hi.  There's something I don't understand.  Why does start_subfile not
> prepend dirname to name if the latter is not absolute?  Since
> name,dirname are added to the subfile list if there isn't a match and
> then will later be used to do matches, it seems like we want to
> prepend dirname to the input name before doing FILENAME_CMP.

Yes. This should solve my "problem 1" from
http://sourceware.org/ml/gdb/2008-01/msg00013.html

Thanks.