From: Tom Tromey <tromey@redhat.com>
To: Siva Chandra <sivachandra@google.com>
Cc: gdb-patches@sourceware.org, Doug Evans <dje@google.com>
Subject: Re: [RFC - Python Scripting] New method Objfile.symtabs () - docs included
Date: Mon, 09 Apr 2012 17:56:00 -0000 [thread overview]
Message-ID: <87vcl894da.fsf@fleche.redhat.com> (raw)
In-Reply-To: <CAGyQ6gxnOEjbhtM9k0hv1Hy7cgS9+vwdOPyozuBtCgvNsYa3jg@mail.gmail.com> (Siva Chandra's message of "Fri, 6 Apr 2012 22:11:45 +0530")
>>>>> "Siva" == Siva Chandra <sivachandra@google.com> writes:
Tom> How about just the plain Objfile.iterator(REGEX)?
Tom> It would return an iterator that lazily instantiates symtabs.
Tom> (Or, at least conceptually lazily instantiates them, as it isn't clear
Tom> that this is efficiently implementable with the current
Tom> quick_symbol_functions API.)
Siva> Is this equivalent to what Paul Koning suggests and has the same
Siva> problem which Doug Evans points out (source file matching with a REGEX
Siva> aside)?
More or less. The key thing is to pass a kind of selector to the
iterator so that it can pick which symtabs to expand. This lets you
keep a cap on memory use.
Ultimately if a script asks for all the CUs, memory and CPU are going to
go through the roof. I think it is good to warn about this and provide
ways to work around it, but in the end I don't have a problem with it.
If you want to look at all the symbols in a big program, well, that's
just a lot of work.
Doug> I can think of a simple(quick) solution: create the symtab object when
Doug> the psymtab object is created (suitably modified to clean up anything
Doug> obvious), but not expand it. [btw, Psymtabs at the moment aren't as
Doug> much of an implementation detail as we want them to be (IMO).] It's
Doug> not perfect: Depending on what you want from the symtab you may
Doug> ultimately end up expanding everything anyway. But it's a step. One
Doug> way to go would be to build into gdb the ability to discard the
Doug> expansion say when memory gets tight. I think there's room for
Doug> improvement before we get to that though.
FWIW, I have a 2 part plan for lazy CU expansion that, I think, would
help this situation quite a bit, for DWARF anyway.
The first part is to change the DWARF reader not to fully read symbols,
then change symtab.c to finish filling in a function symbol just before
it is returned, and change SYMBOL_TYPE to lazily read the type.
This is not extremely hard to do, and it both speeds up CU expansion
(just skipping function bodies is worth ~30%) and reduces memory use in
the common case where most symbols in a CU are not needed.
I have a starter patch for the function body part if anybody is curious.
Part 2 is more involved -- change partial symtabs to also record the DIE
offsets, and then change the psymtab -> symtab expander to just copy
this information over. The idea here is that we then don't need to
re-scan .debug_info at all, we're just shuffling some bits around.
Part of this could also be to introduce some memory savings by letting
(some) symbols point to their corresponding partial symbol, instead of
effectively having a copy of the data.
I like the idea of being able to discard symtabs when memory is tight.
Tom
next prev parent reply other threads:[~2012-04-09 17:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-02 6:17 Siva Chandra
2012-04-02 17:08 ` Eli Zaretskii
2012-04-03 0:04 ` Doug Evans
2012-04-03 5:54 ` Siva Chandra
2012-04-05 16:30 ` Paul_Koning
2012-04-05 18:41 ` Tom Tromey
2012-04-05 18:37 ` Tom Tromey
2012-04-05 19:56 ` Paul_Koning
2012-04-05 20:26 ` Doug Evans
2012-04-06 16:42 ` Siva Chandra
2012-04-09 17:56 ` Tom Tromey [this message]
2012-04-09 17:59 ` Doug Evans
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=87vcl894da.fsf@fleche.redhat.com \
--to=tromey@redhat.com \
--cc=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=sivachandra@google.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