MI: -file-list-exec-source-files

MI: -file-list-exec-source-files

[Nick Roberts]

The command "-file-list-exec-source-files" often (always?) prints out each
file twice:

-file-list-exec-source-files
^done,files=[{file="myprog.c",fullname="/home/nickrob/myprog.c"},{file="myprint.c",fullname="/home/nickrob/myprint.c"},{file="myprint.c",fullname="/home/nickrob/myprint.c"},{file="myprog.c",fullname="/home/nickrob/myprog.c"}]

Looking at the code I had hoped that one cane from the symbol table and the
other from the partial symbol table but in fact, when I try it, they both
come from the partial symbol table.  When the program being debugged has lots
of source files (1000's) this is very wasteful, so I would like to make this
command just print out each file once.  Before I do I'd like to ask:

Why does the partial symbol table have duplicate copies?

Is it safe to assume that duplicates will occur consecutively?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI: -file-list-exec-source-files

[Jim Blandy]

Nick Roberts <nickrob@snap.net.nz> writes:
> The command "-file-list-exec-source-files" often (always?) prints out each
> file twice:
>
> -file-list-exec-source-files
> ^done,files=[{file="myprog.c",fullname="/home/nickrob/myprog.c"},{file="myprint.c",fullname="/home/nickrob/myprint.c"},{file="myprint.c",fullname="/home/nickrob/myprint.c"},{file="myprog.c",fullname="/home/nickrob/myprog.c"}]
>
> Looking at the code I had hoped that one cane from the symbol table and the
> other from the partial symbol table but in fact, when I try it, they both
> come from the partial symbol table.  When the program being debugged has lots
> of source files (1000's) this is very wasteful, so I would like to make this
> command just print out each file once.  Before I do I'd like to ask:
>
> Why does the partial symbol table have duplicate copies?
>
> Is it safe to assume that duplicates will occur consecutively?

I think I understand why header files get duplicated, but why .c files
would, too, I don't know.  If you can figure it out, let me know.  (So
I certainly don't know whether they will always appear consecutively.)

Re: MI: -file-list-exec-source-files

[Bob Rossi]

On Fri, Jun 02, 2006 at 12:37:23PM -0700, Jim Blandy wrote:
> 
> Nick Roberts <nickrob@snap.net.nz> writes:
> > The command "-file-list-exec-source-files" often (always?) prints out each
> > file twice:
> >
> > -file-list-exec-source-files
> > ^done,files=[{file="myprog.c",fullname="/home/nickrob/myprog.c"},{file="myprint.c",fullname="/home/nickrob/myprint.c"},{file="myprint.c",fullname="/home/nickrob/myprint.c"},{file="myprog.c",fullname="/home/nickrob/myprog.c"}]
> >
> > Looking at the code I had hoped that one cane from the symbol table and the
> > other from the partial symbol table but in fact, when I try it, they both
> > come from the partial symbol table.  When the program being debugged has lots
> > of source files (1000's) this is very wasteful, so I would like to make this
> > command just print out each file once.  Before I do I'd like to ask:
> >
> > Why does the partial symbol table have duplicate copies?
> >
> > Is it safe to assume that duplicates will occur consecutively?
> 
> I think I understand why header files get duplicated, but why .c files
> would, too, I don't know.  If you can figure it out, let me know.  (So
> I certainly don't know whether they will always appear consecutively.)

I believe this has the same output as 'info sources', so you may want to
changes that as well?

Bob Rossi

Re: MI: -file-list-exec-source-files

[Daniel Jacobowitz]

On Fri, Jun 02, 2006 at 12:29:16PM +1200, Nick Roberts wrote:
> The command "-file-list-exec-source-files" often (always?) prints out each
> file twice:
> 
> -file-list-exec-source-files
> ^done,files=[{file="myprog.c",fullname="/home/nickrob/myprog.c"},{file="myprint.c",fullname="/home/nickrob/myprint.c"},{file="myprint.c",fullname="/home/nickrob/myprint.c"},{file="myprog.c",fullname="/home/nickrob/myprog.c"}]
> 
> Looking at the code I had hoped that one cane from the symbol table and the
> other from the partial symbol table but in fact, when I try it, they both
> come from the partial symbol table.  When the program being debugged has lots
> of source files (1000's) this is very wasteful, so I would like to make this
> command just print out each file once.  Before I do I'd like to ask:
> 
> Why does the partial symbol table have duplicate copies?

I believe, last time I looked at this, that it has something to do
with getting a symbol file from the symbolic dwarf debug information
(.debug_info) and another from the main entry in the line table.

However, that was a long time ago.  You'd have to debug it.

> Is it safe to assume that duplicates will occur consecutively?

No, since we don't know why they occur ;-)  Also, the debug information
may actually have multiple entries for one file; GDB doesn't try to
rejoin them into a single file.  Some compilers do this.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: -file-list-exec-source-files

[susan]

>Subject: Re: MI: -file-list-exec-source-files
>Jim Blandy <jimb@codesourcery.com> wrote:
>
>Nick Roberts <nickrob@snap.net.nz> writes:
>> The command "-file-list-exec-source-files" often (always?) prints out each
>> file twice:
>>
>> -file-list-exec-source-files
>> >done,files=[{file="myprog.c",fullname="/home/nickrob/myprog.c"},{file="myprint.c",fullname="/home/nickrob/myprint.c"},{file="myprint.c",fullname="/home/nickrob/myprint.c"},{file="myprog.c",fullname="/home/nickrob/myprog.c"}]
>>
>> Looking at the code I had hoped that one cane from the symbol table and the
>> other from the partial symbol table but in fact, when I try it, they both
>> come from the partial symbol table.  When the program being debugged has lots
>> of source files (1000's) this is very wasteful, so I would like to make this
>> command just print out each file once.  Before I do I'd like to ask:
>>
>> Why does the partial symbol table have duplicate copies?
>>
>> Is it safe to assume that duplicates will occur consecutively?
>
>I think I understand why header files get duplicated, but why .c files
>would, too, I don't know.  If you can figure it out, let me know.  (So
>I certainly don't know whether they will always appear consecutively.)

This can happen with .c files too.  It depends on *how* they are compiled.  
Each represents a compilation unit (or something like that).  Imagine you 
have foo.c which includes foo.h that has "#ifdef SOMETHING".  In one 
instance you compile foo.c with SOMETHING defined, another without.  
Then link then together.  You will have 2 instances of foo.c, in this case.

(BTW, if this message is not part of the thread it is because I subscribe to the digest.
Apologies in advance)

Regards,

 
_____________________________ 
Susan Macchia 
mailto:susan@smacchia.net 
http://www.smacchia.net 
_____________________________ 

Re: MI: -file-list-exec-source-files

[Jim Blandy]

<susan@smacchia.net> writes:
>>Subject: Re: MI: -file-list-exec-source-files
>>Jim Blandy <jimb@codesourcery.com> wrote:
>>
>>Nick Roberts <nickrob@snap.net.nz> writes:
>>> The command "-file-list-exec-source-files" often (always?) prints out each
>>> file twice:
>>>
>>> -file-list-exec-source-files
>>> >done,files=[{file="myprog.c",fullname="/home/nickrob/myprog.c"},{file="myprint.c",fullname="/home/nickrob/myprint.c"},{file="myprint.c",fullname="/home/nickrob/myprint.c"},{file="myprog.c",fullname="/home/nickrob/myprog.c"}]
>>>
>>> Looking at the code I had hoped that one cane from the symbol table and the
>>> other from the partial symbol table but in fact, when I try it, they both
>>> come from the partial symbol table.  When the program being debugged has lots
>>> of source files (1000's) this is very wasteful, so I would like to make this
>>> command just print out each file once.  Before I do I'd like to ask:
>>>
>>> Why does the partial symbol table have duplicate copies?
>>>
>>> Is it safe to assume that duplicates will occur consecutively?
>>
>>I think I understand why header files get duplicated, but why .c files
>>would, too, I don't know.  If you can figure it out, let me know.  (So
>>I certainly don't know whether they will always appear consecutively.)
>
> This can happen with .c files too.  It depends on *how* they are compiled.  
> Each represents a compilation unit (or something like that).  Imagine you 
> have foo.c which includes foo.h that has "#ifdef SOMETHING".  In one 
> instance you compile foo.c with SOMETHING defined, another without.  
> Then link then together.  You will have 2 instances of foo.c, in this case.

I don't think this is what's going on here.  I think that even if you
aren't doing any tricks of that sort, the psymtab table ends up with
duplicate entries.

> (BTW, if this message is not part of the thread it is because I subscribe to the digest.
> Apologies in advance)

(It seems to be part of the thread.)

Re: MI: -file-list-exec-source-files

[Susan Macchia]

--- Jim Blandy <jimb@codesourcery.com> wrote:

> 
> Susan Macchia <susan@smacchia.net> writes:
> >>Subject: Re: MI: -file-list-exec-source-files
> >>Jim Blandy <jimb@codesourcery.com> wrote:
> >>
> >>Nick Roberts <nickrob@snap.net.nz> writes:
> >>> The command "-file-list-exec-source-files" often (always?) prints out
> each
> >>> file twice:
> >>>
> >>> -file-list-exec-source-files
> >>>
>
>done,files=[{file="myprog.c",fullname="/home/nickrob/myprog.c"},{file="myprint.c",fullname="/home/nickrob/myprint.c"},{file="myprint.c",fullname="/home/nickrob/myprint.c"},{file="myprog.c",fullname="/home/nickrob/myprog.c"}]
> >>>
> >>> Looking at the code I had hoped that one cane from the symbol table and
> the
> >>> other from the partial symbol table but in fact, when I try it, they both
> >>> come from the partial symbol table.  When the program being debugged has
> lots
> >>> of source files (1000's) this is very wasteful, so I would like to make
> this
> >>> command just print out each file once.  Before I do I'd like to ask:
> >>>
> >>> Why does the partial symbol table have duplicate copies?
> >>>
> >>> Is it safe to assume that duplicates will occur consecutively?
> >>
> >>I think I understand why header files get duplicated, but why .c files
> >>would, too, I don't know.  If you can figure it out, let me know.  (So
> >>I certainly don't know whether they will always appear consecutively.)
> >
> > This can happen with .c files too.  It depends on *how* they are compiled. 
> 
> > Each represents a compilation unit (or something like that).  Imagine you 
> > have foo.c which includes foo.h that has "#ifdef SOMETHING".  In one 
> > instance you compile foo.c with SOMETHING defined, another without.  
> > Then link then together.  You will have 2 instances of foo.c, in this case.
> 
> I don't think this is what's going on here.  I think that even if you
> aren't doing any tricks of that sort, the psymtab table ends up with
> duplicate entries.

Perhaps, but in working on the UI for other debuggers, I have seen this and 
it looked like the same situation.  When I worked on Compaq ladebug, we had 
to get the list of source files so that the user could choose one to set 
bpts in, or to browse.  In retrieving that list from the debugger, I saw e
xactly what Nick is seeing.  And in delving into the internals of the 
debugger/compiler, I found that the situation I described, with foo.? to 
be why I saw more than one source.  This is especially true for C++ when
templates are used.   What you really want to see in a list like this is 
"foo.c compiled this way", "foo.c compiled that way", and so on.  I don't 
think any debugger has solved this problem reasonably from a UI perspective.

> 
> > (BTW, if this message is not part of the thread it is because I subscribe
> to the digest.
> > Apologies in advance)
> 
> (It seems to be part of the thread.)
phew ;) 


_____________________________
Susan Macchia
mailto:susan@smacchia.net
http://www.smacchia.net
_____________________________

Re: MI: -file-list-exec-source-files

[Nick Roberts]

 > Perhaps, but in working on the UI for other debuggers, I have seen this and 
 > it looked like the same situation.  When I worked on Compaq ladebug, we had 
 > to get the list of source files so that the user could choose one to set 
 > bpts in, or to browse.  In retrieving that list from the debugger, I saw e
 > xactly what Nick is seeing.  And in delving into the internals of the 
 > debugger/compiler, I found that the situation I described, with foo.? to 
 > be why I saw more than one source.  This is especially true for C++ when
 > templates are used.   What you really want to see in a list like this is 
 > "foo.c compiled this way", "foo.c compiled that way", and so on.  I don't 
 > think any debugger has solved this problem reasonably from a UI perspective.

I think it's always best to start with the simplest case:

mytest.c:

main ()
{
  myproc ();
}


myproc.c:

myproc ()
{
  return 0;
}

With gcc (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3)
cc -g -c myproc.c
cc -g -o mytest mytest.c myproc.o

With GNU gdb 6.5.50.20060601-cvs, I get:

(gdb)
-file-list-exec-source-files
^done,files=[{file="myproc.c",fullname="/home/nickrob/myproc.c"},{file="myproc.c",fullname="/home/nickrob/myproc.c"},{file="mytest.c",fullname="/home/nickrob/mytest.c"},{file="mytest.c",fullname="/home/nickrob/mytest.c"}]

From what people have said, I guess a different compiler may give a different
result.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI: -file-list-exec-source-files

[Eli Zaretskii]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5641 bytes --]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 3 Jun 2006 13:27:48 +1200
> Cc: Jim Blandy <jimb@codesourcery.com>, gdb@sourceware.org
> 
> I think it's always best to start with the simplest case:
> 
> mytest.c:
> 
> main ()
> {
>   myproc ();
> }
> 
> 
> myproc.c:
> 
> myproc ()
> {
>   return 0;
> }
> 
> With gcc (GCC) 4.1.0 20060304 (Red Hat 4.1.0-3)
> cc -g -c myproc.c
> cc -g -o mytest mytest.c myproc.o
> 
> With GNU gdb 6.5.50.20060601-cvs, I get:
> 
> (gdb)
> -file-list-exec-source-files
> ^done,files=[{file="myproc.c",fullname="/home/nickrob/myproc.c"},{file="myproc.c",fullname="/home/nickrob/myproc.c"},{file="mytest.c",fullname="/home/nickrob/mytest.c"},{file="mytest.c",fullname="/home/nickrob/mytest.c"}]


With GDB 6.4 and GCC 3.3.5, just stepping through the code of
mi_cmd_file_list_exec_source_files, I clearly see that there are two
psymtab entries for each source file:

    (top-gdb) br mi_cmd_file_list_exec_source_files
    Breakpoint 3 at 0x80bf7c8: file ../gdb/mi/mi-cmd-file.c, line 74.
    (top-gdb) cd ../..
    Working directory /home/e/eliz.
    (top-gdb) r --interpreter=mi ./mytest
    Starting program: /home/e/eliz/gdb-6.4/gdb/gdb --interpreter=mi ./mytest
    ~"GNU gdb 6.4\n"
    ~"Copyright 2005 Free Software Foundation, Inc.\n"
    ~"GDB is free software, covered by the GNU General Public License, and you are\n"
    ~"welcome to change it and/or distribute copies of it under certain conditions.\n"
    ~"Type \"show copying\" to see the conditions.\n"
    ~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
    ~"This GDB was configured as \"i686-pc-linux-gnu\"..."
    ~"Using host libthread_db library \"/lib/tls/libthread_db.so.1\".\n"
    ~"\n"
    (gdb)
    -file-list-exec-source-files

    Breakpoint 3, mi_cmd_file_list_exec_source_files (
	command=0x83304b0 "file-list-exec-source-files", argv=
    During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x80bf7c8.
    0x83304b0, argc=137561264) at ../gdb/mi/mi-cmd-file.c:74
    74        if (!mi_valid_noargs ("mi_cmd_file_list_exec_source_files", argc, argv))
    (top-gdb) n
    78        ui_out_begin (uiout, ui_out_type_list, "files");
    (top-gdb) n
    81        ALL_SYMTABS (objfile, s)
    (top-gdb) n
    97        ALL_PSYMTABS (objfile, ps)
    (top-gdb) p *objfile
    $3 = {next = 0x0, name = 0x8312838 "/home/e/eliz/mytest", flags = 6,
      symtabs = 0x0, psymtabs = 0x8335740, free_psymtabs = 0x0, obfd = 0x8312878,
      mtime = 1149325604, objfile_obstack = {chunk_size = 4072, chunk = 0x83356e0,
      [...]
      stats = {n_minsyms = 36, n_psyms = 109, n_syms = 0, n_stabs = 0,
	n_types = 0, sz_strtab = 0}, cp_namespace_symtab = 0x0}
    (top-gdb) p *objfile->psymtabs
    $4 = {next = 0x83356e8,
      filename = 0x8335788 "/build/buildd/glibc-2.3.2.ds1/build-tree/i386-libc/csu/crtn.S", fullname = 0x0,
      dirname = 0x8330470 "/build/buildd/glibc-2.3.2.ds1/build-tree/glibc-2.3.2/csu", objfile = 0x8326a98, section_offsets = 0x832cd6c, textlow = 0, texthigh = 0,
      dependencies = 0x0, number_of_dependencies = 0, globals_offset = 3,
      n_global_syms = 0, statics_offset = 106, n_static_syms = 0, symtab = 0x0,
      read_symtab = 0x814e870 <dwarf2_psymtab_to_symtab>,
      read_symtab_private = 0x8331e38 "±\n", readin = 0 '\0'}
    (top-gdb) p *objfile->psymtabs->next
    $5 = {next = 0x8332694, filename = 0x8335730 "myproc.c", fullname = 0x0,
      dirname = 0x0, objfile = 0x8326a98, section_offsets = 0x832cd6c,
      textlow = 0, texthigh = 0, dependencies = 0x833573c,
      number_of_dependencies = 1, globals_offset = 0, n_global_syms = 0,
      statics_offset = 0, n_static_syms = 0, symtab = 0x0,
      read_symtab = 0x814e870 <dwarf2_psymtab_to_symtab>,
      read_symtab_private = 0x0, readin = 0 '\0'}
    (top-gdb) p *objfile->psymtabs->next->next
    $6 = {next = 0x833263c, filename = 0x83326dc "myproc.c", fullname = 0x0,
      dirname = 0x8314b70 "/home/e/eliz", objfile = 0x8326a98,
      section_offsets = 0x832cd6c, textlow = 134513516, texthigh = 134513526,
      dependencies = 0x0, number_of_dependencies = 0, globals_offset = 2,
      n_global_syms = 1, statics_offset = 105, n_static_syms = 1, symtab = 0x0,
      read_symtab = 0x814e870 <dwarf2_psymtab_to_symtab>,
      read_symtab_private = 0x8331e24 "9\n", readin = 0 '\0'}
    (top-gdb) p *objfile->psymtabs->next->next->next
    $7 = {next = 0x83325e8, filename = 0x8332684 "mytest.c", fullname = 0x0,
      dirname = 0x0, objfile = 0x8326a98, section_offsets = 0x832cd6c,
      textlow = 0, texthigh = 0, dependencies = 0x8332690,
      number_of_dependencies = 1, globals_offset = 0, n_global_syms = 0,
      statics_offset = 0, n_static_syms = 0, symtab = 0x0,
      read_symtab = 0x814e870 <dwarf2_psymtab_to_symtab>,
      read_symtab_private = 0x0, readin = 0 '\0'}
    (top-gdb) p *objfile->psymtabs->next->next->next->next
    $8 = {next = 0x8332560, filename = 0x8332630 "mytest.c", fullname = 0x0,
      dirname = 0x8314300 "/home/e/eliz", objfile = 0x8326a98,
      section_offsets = 0x832cd6c, textlow = 134513492, texthigh = 134513515,
      dependencies = 0x0, number_of_dependencies = 0, globals_offset = 1,
      n_global_syms = 1, statics_offset = 104, n_static_syms = 1, symtab = 0x0,
      read_symtab = 0x814e870 <dwarf2_psymtab_to_symtab>,
      read_symtab_private = 0x8331e10 "¬\t", readin = 0 '\0'}
    (top-gdb)

As you see, there are two entries for myproc.c and two entries for
mytest.c, one with a NULL dirname, the other with a non-NULL dirname.

Sounds like we should implement duplicate removal from the UI lists?

Re: MI: -file-list-exec-source-files

[Nick Roberts]

 >...
 >     (top-gdb) p *objfile->psymtabs->next->next->next
 >     $7 = {next = 0x83325e8, filename = 0x8332684 "mytest.c", fullname = 0x0,
 >       dirname = 0x0, objfile = 0x8326a98, section_offsets = 0x832cd6c,
 >       textlow = 0, texthigh = 0, dependencies = 0x8332690,
 >       number_of_dependencies = 1, globals_offset = 0, n_global_syms = 0,
 >       statics_offset = 0, n_static_syms = 0, symtab = 0x0,
 >       read_symtab = 0x814e870 <dwarf2_psymtab_to_symtab>,
 >       read_symtab_private = 0x0, readin = 0 '\0'}
 >     (top-gdb) p *objfile->psymtabs->next->next->next->next
 >     $8 = {next = 0x8332560, filename = 0x8332630 "mytest.c", fullname = 0x0,
 >       dirname = 0x8314300 "/home/e/eliz", objfile = 0x8326a98,
 >       section_offsets = 0x832cd6c, textlow = 134513492, texthigh = 134513515,
 >       dependencies = 0x0, number_of_dependencies = 0, globals_offset = 1,
 >       n_global_syms = 1, statics_offset = 104, n_static_syms = 1, symtab = 0x0,
 >       read_symtab = 0x814e870 <dwarf2_psymtab_to_symtab>,
 >       read_symtab_private = 0x8331e10 "¬\t", readin = 0 '\0'}
 >     (top-gdb)
 > 
 > As you see, there are two entries for myproc.c and two entries for
 > mytest.c, one with a NULL dirname, the other with a non-NULL dirname.

Yes, I can see the duplicate entries

 > Sounds like we should implement duplicate removal from the UI lists?

I'm not sure.  It may take GDB longer to remove the duplicate entries than
it does for Emacs to read them.  It would be best not to create them in the
first place, but maybe that's not easily done.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI: -file-list-exec-source-files

[Daniel Jacobowitz]

On Sun, Jun 04, 2006 at 10:25:33AM +1200, Nick Roberts wrote:
>  > As you see, there are two entries for myproc.c and two entries for
>  > mytest.c, one with a NULL dirname, the other with a non-NULL dirname.
> 
> Yes, I can see the duplicate entries

But Eli's got a good point: the one with a NULL dirname is at best
sub-optimal.

>  > Sounds like we should implement duplicate removal from the UI lists?
> 
> I'm not sure.  It may take GDB longer to remove the duplicate entries than
> it does for Emacs to read them.  It would be best not to create them in the
> first place, but maybe that's not easily done.

There are two potential sources of duplication: bugs, e.g. in our
processing of symbol vs. line information, and actual duplicate entries
in the debug info.  As Susan correctly noted, the duplicates are often
legitimate and discarding them entirely would be bad.  But it sounds
like the ones you're observing are the result of a bug.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: -file-list-exec-source-files

[Nick Roberts]

 > >  > As you see, there are two entries for myproc.c and two entries for
 > >  > mytest.c, one with a NULL dirname, the other with a non-NULL dirname.
 > > 
 > > Yes, I can see the duplicate entries
 > 
 > But Eli's got a good point: the one with a NULL dirname is at best
 > sub-optimal.

Can we just remove that one then?

 > >  > Sounds like we should implement duplicate removal from the UI lists?
 > > 
 > > I'm not sure.  It may take GDB longer to remove the duplicate entries than
 > > it does for Emacs to read them.  It would be best not to create them in the
 > > first place, but maybe that's not easily done.
 > 
 > There are two potential sources of duplication: bugs, e.g. in our
 > processing of symbol vs. line information, and actual duplicate entries
 > in the debug info.  As Susan correctly noted, the duplicates are often
 > legitimate and discarding them entirely would be bad.  

OK, I didn't realise that.  How do we distinguish between these and those
which aren't needed?  Will the legitimate ones always have a non-NULL dirname

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI: -file-list-exec-source-files

[Daniel Jacobowitz]

On Sun, Jun 04, 2006 at 12:03:33PM +1200, Nick Roberts wrote:
>  > >  > Sounds like we should implement duplicate removal from the UI lists?
>  > > 
>  > > I'm not sure.  It may take GDB longer to remove the duplicate entries than
>  > > it does for Emacs to read them.  It would be best not to create them in the
>  > > first place, but maybe that's not easily done.
>  > 
>  > There are two potential sources of duplication: bugs, e.g. in our
>  > processing of symbol vs. line information, and actual duplicate entries
>  > in the debug info.  As Susan correctly noted, the duplicates are often
>  > legitimate and discarding them entirely would be bad.  
> 
> OK, I didn't realise that.  How do we distinguish between these and those
> which aren't needed?  Will the legitimate ones always have a non-NULL dirname

Let me try being more explicit about this, since I think I'm not
communicating :-)

It sounds like a bug, or at least sub-optimal behavior, in the dwarf
reader.  Someone should figure out why it happens, and how to stop it.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: -file-list-exec-source-files

[Eli Zaretskii]

> Date: Sat, 3 Jun 2006 18:35:37 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, susan@smacchia.net, jimb@codesourcery.com,
> 	gdb@sourceware.org
> 
> >  > Sounds like we should implement duplicate removal from the UI lists?
> > 
> > I'm not sure.  It may take GDB longer to remove the duplicate entries than
> > it does for Emacs to read them.  It would be best not to create them in the
> > first place, but maybe that's not easily done.
> 
> There are two potential sources of duplication: bugs, e.g. in our
> processing of symbol vs. line information, and actual duplicate entries
> in the debug info.  As Susan correctly noted, the duplicates are often
> legitimate and discarding them entirely would be bad.  But it sounds
> like the ones you're observing are the result of a bug.

If the duplicates are due to a bug, then we should fix the bug.
Otherwise, the only way not to have the duplicates is to detect them
and remove them.

FWIW, GDB 6.3 doesn't seem to have this problem, AFAICS:

    eliz@fencepost:~$ ./gdb-6.3/gdb/gdb --interpreter=mi2 ./mytest
    ~"GNU gdb 6.3\n"
    ~"Copyright 2004 Free Software Foundation, Inc.\n"
    ~"GDB is free software, covered by the GNU General Public License, and you are\n"
    ~"welcome to change it and/or distribute copies of it under certain conditions.\n"
    ~"Type \"show copying\" to see the conditions.\n"
    ~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
    ~"This GDB was configured as \"i686-pc-linux-gnu\"..."
    ~"Using host libthread_db library \"/lib/tls/libthread_db.so.1\".\n"
    ~"\n"
    (gdb)
    -file-list-exec-source-files
    ^done,files=[{file="crtn.S"},{file="/build/buildd/glibc-2.3.2.ds1/build-tree/i386-libc/csu/crtn.S"},{file="myproc.c",fullname="/home/e/eliz/myproc.c"},{file="mytest.c",fullname="/home/e/eliz/mytest.c"},{file="crti.S"},{file="/build/buildd/glibc-2.3.2.ds1/build-tree/i386-libc/csu/crti.S"},{file="init.c"},{file="start.S"},{file="../sysdeps/i386/elf/start.S"}]

Re: MI: -file-list-exec-source-files

[Nick Roberts]

 > FWIW, GDB 6.3 doesn't seem to have this problem, AFAICS:
 > 
 >     eliz@fencepost:~$ ./gdb-6.3/gdb/gdb --interpreter=mi2 ./mytest
 >     ~"GNU gdb 6.3\n"
 >     ~"Copyright 2004 Free Software Foundation, Inc.\n"
 >     ~"GDB is free software, covered by the GNU General Public License, and you are\n"
 >     ~"welcome to change it and/or distribute copies of it under certain conditions.\n"
 >     ~"Type \"show copying\" to see the conditions.\n"
 >     ~"There is absolutely no warranty for GDB.  Type \"show warranty\" for details.\n"
 >     ~"This GDB was configured as \"i686-pc-linux-gnu\"..."
 >     ~"Using host libthread_db library \"/lib/tls/libthread_db.so.1\".\n"
 >     ~"\n"
 >     (gdb)
 >     -file-list-exec-source-files
 >     ^done,files=[{file="crtn.S"},{file="/build/buildd/glibc-2.3.2.ds1/build-tree/i386-libc/csu/crtn.S"},{file="myproc.c",fullname="/home/e/eliz/myproc.c"},{file="mytest.c",fullname="/home/e/eliz/mytest.c"},{file="crti.S"},{file="/build/buildd/glibc-2.3.2.ds1/build-tree/i386-libc/csu/crti.S"},{file="init.c"},{file="start.S"},{file="../sysdeps/i386/elf/start.S"}]

Yes, I see this too:

nickrob/194 src/gdb/gdb mytest
GGNU gdb 6.5.50.20060601-cvs
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) maint info psymtab
{ objfile /home/nickrob/mytest ((struct objfile *) 0x90877f8)
  { psymtab myproc.c ((struct partial_symtab *) 0x9091e9c)
    readin no
    fullname (null)
    text addresses 0x0 -- 0x0
    globals (none)
    statics (none)
    dependencies {
      psymtab myproc.c ((struct partial_symtab *) 0x908d820)
    }
  }
  { psymtab myproc.c ((struct partial_symtab *) 0x908d820)
    readin no
    fullname (null)
    text addresses 0x8048380 -- 0x8048387
    globals (* (struct partial_symbol **) 0x9075874 @ 1)
    statics (* (struct partial_symbol **) 0x908d8bc @ 1)
    dependencies (none)
  }
  { psymtab mytest.c ((struct partial_symtab *) 0x908d7c8)
    readin no
    fullname (null)
    text addresses 0x0 -- 0x0
    globals (none)
    statics (none)
    dependencies {
      psymtab mytest.c ((struct partial_symtab *) 0x908d76c)
    }
  }
  { psymtab mytest.c ((struct partial_symtab *) 0x908d76c)
    readin no
    fullname (null)
    text addresses 0x8048360 -- 0x804837f
    globals (* (struct partial_symbol **) 0x9075870 @ 1)
    statics (* (struct partial_symbol **) 0x908d8b8 @ 1)
    dependencies (none)
  }
}


nickrob/195 gdb mytest
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) maint info psymtab
{ objfile /home/nickrob/mytest ((struct objfile *) 0x9cffd70)
  { psymtab myproc.c ((struct partial_symtab *) 0x9d05cf8)
    readin no
    fullname (null)
    text addresses 0x8048380 -- 0x8048387
    globals (* (struct partial_symbol **) 0x9ceddfc @ 1)
    statics (* (struct partial_symbol **) 0x9d05e54 @ 1)
    dependencies (none)
  }
  { psymtab mytest.c ((struct partial_symtab *) 0x9d05c9c)
    readin no
    fullname (null)
    text addresses 0x8048360 -- 0x804837f
    globals (* (struct partial_symbol **) 0x9ceddf8 @ 1)
    statics (* (struct partial_symbol **) 0x9d05e50 @ 1)
    dependencies (none)
  }
}


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI: -file-list-exec-source-files

[Bob Rossi]

> Perhaps, but in working on the UI for other debuggers, I have seen this and 
> it looked like the same situation.  When I worked on Compaq ladebug, we had 
> to get the list of source files so that the user could choose one to set 
> bpts in, or to browse.  In retrieving that list from the debugger, I saw e
> xactly what Nick is seeing.  And in delving into the internals of the 
> debugger/compiler, I found that the situation I described, with foo.? to 
> be why I saw more than one source.  This is especially true for C++ when
> templates are used.   What you really want to see in a list like this is 
> "foo.c compiled this way", "foo.c compiled that way", and so on.  I don't 
> think any debugger has solved this problem reasonably from a UI perspective.

Even if this was true, I still think the duplicates make no sense with
the information that -file-list-exec-source-files currently provides.
The front end will use the file as is, so having 1 or N of those files
just makes more I/O at this point.

Bob Rossi