This is the mail archive of the gdb@sources.redhat.com 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] |
> Hmm, begs a few questions:
sorry, I am talking about partial symbols. It's not clear from the above.
> > - why do we load the symbols during startup?
> Load globals on demand?
What sort of demand do you have in mind?The very first lookup_symbol_by_name().
> - why do we sort the symbols during startup?
> Use a hash (so that break main is fast) and sort when (break main<tab> > is entered?)
> - why don't we do more while GDB is twiddling its thumbs in the event > loop event loop?
Hmm.... that's pretty complicated to implement. It would require doing things in small chunks and handling interruption gracefully. The problem is, at the first symbol lookup, we will probably need to have all the symbols...
$ gdb foo (gdb) break main (gdb) run
The thing that I am curious about is to see how early into a regular debug session we build the symtabs. I.e. I am afraid that any reference to any symbol from the command line makes the whole lot expand anyway. The answer to this may help answer the question whether we really need a two tier symbol table system, or if there is another way of solving the same problem. While cleaning up the obstack stuff, it became obvious that the intent was for the psymtabs to go away once expanded into full symtabs, but this was never implemented.
enjoy, Andrew
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |