whodunnit? info sources now returns duplicates

whodunnit? info sources now returns duplicates

[David Lecomber]

This is a regression bug -- the version I have tested this are 
from CVS on 2004-08-17, and 2004-06-22.  

Any test program:

foo/test.c

int main() {
	int x;
}

now compile - but in the directory above foo.

gcc -g foo/test.c

run gdb ./a.out 

For 20040622, only foo/test.c is listed in info sources (correct)
For 20040817 (and recent 20040913) foo/test.c and test.c are listed..
(incorrect)

When you add a breakpoint to main, and do info sources, the duplicate
vanishes..

Any takers?

d.

Re: whodunnit? info sources now returns duplicates

[Andrew Cagney]

Lets use this to remind ourselves that what we don't test (as in 
gdb/testsuite/) doesn't work.

Andrew

> This is a regression bug -- the version I have tested this are 
> from CVS on 2004-08-17, and 2004-06-22.  
> 
> Any test program:
> 
> foo/test.c
> 
> int main() {
> 	int x;
> }
> 
> now compile - but in the directory above foo.
> 
> gcc -g foo/test.c
> 
> run gdb ./a.out 
> 
> For 20040622, only foo/test.c is listed in info sources (correct)
> For 20040817 (and recent 20040913) foo/test.c and test.c are listed..
> (incorrect)
> 
> When you add a breakpoint to main, and do info sources, the duplicate
> vanishes..

Re: whodunnit? info sources now returns duplicates

[Daniel Jacobowitz]

On Wed, Sep 15, 2004 at 11:14:56AM +0100, David Lecomber wrote:
> This is a regression bug -- the version I have tested this are 
> from CVS on 2004-08-17, and 2004-06-22.  
> 
> Any test program:
> 
> foo/test.c
> 
> int main() {
> 	int x;
> }
> 
> now compile - but in the directory above foo.
> 
> gcc -g foo/test.c
> 
> run gdb ./a.out 
> 
> For 20040622, only foo/test.c is listed in info sources (correct)
> For 20040817 (and recent 20040913) foo/test.c and test.c are listed..
> (incorrect)
> 
> When you add a breakpoint to main, and do info sources, the duplicate
> vanishes..
> 
> Any takers?

Joel's patch to dwarf2read to create symtabs based on the line table
also creates symtabs if the name of the compilation unit and the name
in the line table don't match.  I noticed this last week and don't know
what to do about it.

One workaround is a patch I whipped together to display the fullname in
info sources output (arguably more useful anyway).  The two will have
the same fullnames and we already have code to suppress printing the
duplicates.  Attached.

What do you think?

-- 
Daniel Jacobowitz

Index: gdb/symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.136
diff -u -p -r1.136 symtab.c
--- gdb/symtab.c	11 Sep 2004 10:24:51 -0000	1.136
+++ gdb/symtab.c	14 Sep 2004 23:35:12 -0000
@@ -69,7 +69,7 @@ static void variables_info (char *, int)
 
 static void sources_info (char *, int);
 
-static void output_source_filename (char *, int *);
+static void output_source_filename (const char *, int *);
 
 static int find_line_common (struct linetable *, int, int *);
 
@@ -2622,7 +2622,7 @@ filename_seen (const char *file, int add
    NAME is the name to print and *FIRST is nonzero if this is the first
    name printed.  Set *FIRST to zero.  */
 static void
-output_source_filename (char *name, int *first)
+output_source_filename (const char *name, int *first)
 {
   /* Since a single source file can result in several partial symbol
      tables, we need to avoid printing it more than once.  Note: if
@@ -2671,7 +2671,8 @@ sources_info (char *ignore, int from_tty
   first = 1;
   ALL_SYMTABS (objfile, s)
   {
-    output_source_filename (s->filename, &first);
+    const char *fullname = symtab_to_fullname (s);
+    output_source_filename (fullname ? fullname : s->filename, &first);
   }
   printf_filtered ("\n\n");
 
@@ -2682,7 +2683,8 @@ sources_info (char *ignore, int from_tty
   {
     if (!ps->readin)
       {
-	output_source_filename (ps->filename, &first);
+	const char *fullname = psymtab_to_fullname (ps);
+	output_source_filename (fullname ? fullname : ps->filename, &first);
       }
   }
   printf_filtered ("\n");

Re: whodunnit? info sources now returns duplicates

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:
> On Wed, Sep 15, 2004 at 11:14:56AM +0100, David Lecomber wrote:
> > This is a regression bug -- the version I have tested this are 
> > from CVS on 2004-08-17, and 2004-06-22.  
> > 
> > Any test program:
> > 
> > foo/test.c
> > 
> > int main() {
> > 	int x;
> > }
> > 
> > now compile - but in the directory above foo.
> > 
> > gcc -g foo/test.c
> > 
> > run gdb ./a.out 
> > 
> > For 20040622, only foo/test.c is listed in info sources (correct)
> > For 20040817 (and recent 20040913) foo/test.c and test.c are listed..
> > (incorrect)
> > 
> > When you add a breakpoint to main, and do info sources, the duplicate
> > vanishes..
> > 
> > Any takers?
> 
> Joel's patch to dwarf2read to create symtabs based on the line table
> also creates symtabs if the name of the compilation unit and the name
> in the line table don't match.  I noticed this last week and don't know
> what to do about it.
> 
> One workaround is a patch I whipped together to display the fullname in
> info sources output (arguably more useful anyway).  The two will have
> the same fullnames and we already have code to suppress printing the
> duplicates.  Attached.
> 
> What do you think?

Looks good to me.  If you've tested it, go ahead and commit.

Re: whodunnit? info sources now returns duplicates

[Andrew Cagney]

> Looks good to me.  If you've tested it, go ahead and commit.

That's using the testsuite, right ;-)

Andrew