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

[Susan Macchia <susan at smacchia dot net>]

--- 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
_____________________________