* whodunnit? info sources now returns duplicates
@ 2004-09-15 10:12 David Lecomber
2004-09-15 17:49 ` Andrew Cagney
2004-09-15 18:10 ` Daniel Jacobowitz
0 siblings, 2 replies; 5+ messages in thread
From: David Lecomber @ 2004-09-15 10:12 UTC (permalink / raw)
To: gdb
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: whodunnit? info sources now returns duplicates
2004-09-15 10:12 whodunnit? info sources now returns duplicates David Lecomber
@ 2004-09-15 17:49 ` Andrew Cagney
2004-09-15 18:10 ` Daniel Jacobowitz
1 sibling, 0 replies; 5+ messages in thread
From: Andrew Cagney @ 2004-09-15 17:49 UTC (permalink / raw)
To: David Lecomber; +Cc: gdb
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..
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: whodunnit? info sources now returns duplicates
2004-09-15 10:12 whodunnit? info sources now returns duplicates David Lecomber
2004-09-15 17:49 ` Andrew Cagney
@ 2004-09-15 18:10 ` Daniel Jacobowitz
2004-09-15 22:11 ` Jim Blandy
1 sibling, 1 reply; 5+ messages in thread
From: Daniel Jacobowitz @ 2004-09-15 18:10 UTC (permalink / raw)
To: David Lecomber; +Cc: gdb
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");
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: whodunnit? info sources now returns duplicates
2004-09-15 18:10 ` Daniel Jacobowitz
@ 2004-09-15 22:11 ` Jim Blandy
2004-09-16 16:26 ` Andrew Cagney
0 siblings, 1 reply; 5+ messages in thread
From: Jim Blandy @ 2004-09-15 22:11 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: David Lecomber, gdb
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: whodunnit? info sources now returns duplicates
2004-09-15 22:11 ` Jim Blandy
@ 2004-09-16 16:26 ` Andrew Cagney
0 siblings, 0 replies; 5+ messages in thread
From: Andrew Cagney @ 2004-09-16 16:26 UTC (permalink / raw)
To: Jim Blandy; +Cc: Daniel Jacobowitz, David Lecomber, gdb
> Looks good to me. If you've tested it, go ahead and commit.
That's using the testsuite, right ;-)
Andrew
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-09-16 16:26 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-15 10:12 whodunnit? info sources now returns duplicates David Lecomber
2004-09-15 17:49 ` Andrew Cagney
2004-09-15 18:10 ` Daniel Jacobowitz
2004-09-15 22:11 ` Jim Blandy
2004-09-16 16:26 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).