From: Jim Blandy <jimb@codesourcery.com>
To: <susan@smacchia.net>
Cc: gdb@sourceware.org
Subject: Re: MI: -file-list-exec-source-files
Date: Sat, 03 Jun 2006 00:05:00 -0000 [thread overview]
Message-ID: <vt23benkssp.fsf@theseus.home.> (raw)
In-Reply-To: <20060602233144.10238.qmail@web51811.mail.yahoo.com> (susan@smacchia.net's message of "Fri, 2 Jun 2006 16:31:44 -0700 (PDT)")
<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.)
next prev parent reply other threads:[~2006-06-03 0:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1149277048.21408.ezmlm@sourceware.org>
2006-06-02 23:31 ` susan
2006-06-03 0:05 ` Jim Blandy [this message]
2006-06-03 0:46 ` Susan Macchia
2006-06-03 1:28 ` Nick Roberts
2006-06-03 9:46 ` Eli Zaretskii
2006-06-03 22:26 ` Nick Roberts
2006-06-03 22:35 ` Daniel Jacobowitz
2006-06-04 0:04 ` Nick Roberts
2006-06-04 2:50 ` Daniel Jacobowitz
2006-06-04 3:34 ` Eli Zaretskii
2006-06-06 8:01 ` Nick Roberts
2006-06-03 1:39 ` Bob Rossi
2006-06-02 0:30 Nick Roberts
2006-06-02 19:37 ` Jim Blandy
2006-06-02 19:38 ` Bob Rossi
2006-06-02 20:24 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vt23benkssp.fsf@theseus.home. \
--to=jimb@codesourcery.com \
--cc=gdb@sourceware.org \
--cc=susan@smacchia.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox