This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC - Python Scripting] New method Objfile.symtabs () - docs included


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]