From: Joel Brobecker <brobecker@gnat.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [RFC/dwarf-2] Add support for included files
Date: Sat, 03 Jan 2004 14:42:00 -0000 [thread overview]
Message-ID: <20040103144250.GW820@gnat.com> (raw)
In-Reply-To: <20040102141802.GA28372@nevyn.them.org>
On Fri, Jan 02, 2004 at 09:18:02AM -0500, Daniel Jacobowitz wrote:
> Well, the question is whether this works well enough. Things _are_ in
> these files - DW_AT_decl_file points to them. Do we need to also put
> things into the proper psymtabs?
At this point, I don't see anything else that we need.
> Otherwise the approach seems reasonable.
Thanks. I can submit a proper patch soon, but there is Eli's suggestion,
though:
Eli Zaretskii wrote:
> How about if we only do that scan when the file name is not found in
> the partial symbols, i.e. just before GDB is about to give up and
> report the file as nonexistent? Assuming that the cases you have in
> mind are rare, this would mean faster operation in most cases.
I am a bit relunctant to go that way, because I think the current
approach of using a half-baked psymtabs to hold include files is
a bit too adhoc for my taste. Adding an extra step after having scanned
the psymtab list to iterate over all objfiles, and re-partially scan the
debugging information seems to be going one step further in
``legitimizing'' this adhoc approach. If I were to add this extra step,
I would rather introduce a separate data structure for include files,
and then we could build the list of include files on-the-fly as you
suggest when scanning this list.
Trouble is, we may have also made some assumptions in several
places of GDB's code that the psymtab list contains all source
files. I suspect that the extra step you are suggesting will not
affect most of the instances of the code scaning the psymtab list,
so only a few of them will in fact need to be updated. But I'd rather
fix the build_psymtab phase.
It seems a bit of effort for a gain that we haven't measured.
I would suggest going the simple way first and re-think it if
the performance becomes noticeably worse. If somebody has a large
app like mozilla that he can use to do some measurement, I would
sure appreciate how much slower it is to startup with the patch
I posted.
(Eli, I don't know about C++, but you have a good point about lex & yacc
code)
Let me know what you all think.
Thanks,
--
Joel
next prev parent reply other threads:[~2004-01-03 14:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-02 7:25 Joel Brobecker
2004-01-02 14:18 ` Daniel Jacobowitz
2004-01-03 14:42 ` Joel Brobecker [this message]
2004-01-03 16:34 ` Eli Zaretskii
2004-01-03 17:47 ` Joel Brobecker
2004-01-02 14:45 ` Eli Zaretskii
2004-01-05 16:18 ` Andrew Cagney
2004-01-05 19:17 ` Joel Brobecker
2004-04-07 16:05 Jim Blandy
2004-04-13 5:20 ` Joel Brobecker
2004-04-14 19:10 ` Jim Blandy
2004-04-15 22:13 ` Joel Brobecker
2004-04-16 4:24 ` Jim Blandy
2004-04-16 4:28 ` Joel Brobecker
2004-04-16 23:08 ` Joel Brobecker
2004-04-29 23:32 ` Jim Blandy
2004-05-01 1:14 ` Joel Brobecker
2004-05-01 4:57 ` Jim Blandy
2004-05-03 16:25 ` Joel Brobecker
2004-05-03 22:15 Andrew Pinski
2004-05-04 0:15 ` Joel Brobecker
2004-05-04 0:18 ` Andrew Pinski
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=20040103144250.GW820@gnat.com \
--to=brobecker@gnat.com \
--cc=gdb-patches@sources.redhat.com \
/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