Re: the global symbol table

[Elena Zannoni <ezannoni at redhat dot com>]

I wonder if rewriting the symbol table is really necessary in order to
provide namespace support. I don't want to discourage you though, from
thinking about how to improve things.  Besides, I am a bit behind in my
mail, and I still have to catch up on your progress. Sorry about that.

One thing I found useful doing when I was trying to get a 500ft view
of the symbol table, was to look at how the symbol readers interface with
each other and the rest of gdb.

I looked at the functions that each module provided and noticed that a
few were a bit confused, as to where they belonged, which file
exported what, etc.

I think that an audit of the interfaces could help here as well.
Just a suggestion. And I hope to have time on the weekend to catch up.

Some (not too deep) thoughts below.

David Carlton writes:
 > I'm trying to get a handle on the global symbol table, and on what
 > would be a good way to reorganize its data in order to make
 > lookup_symbol (and related functions, e.g. search_symbol) faster and
 > to provide some sort of data structure that could also be used in
 > namespace searches.
 > 
 > I'm not sure that I have any really coherent questions, so I'm going
 > to free-associate for a while, and see what thoughts that jars loose
 > from other people's brains.  I've listed the main issues that I'm
 > worried about below.
 > 
 > As a reminder, here's what currently happens if you call lookup_symbol
 > and it doesn't find a local match somewhere:
 > 
 > * It looks up the global blocks in all the symtabs, and looks for them
 >   there.  If it finds it, it calls fixup_symbol_section (to get the
 >   bfd_section and section set correctly; this happens in the other
 >   cases below, too) and returns it.
 > * Then, #ifndef HPUXHPPA, it sometimes looks in the minimal symbol
 >   table.  If it finds something, it looks for it in the global and
 >   static blocks of the corresponding symtab.  (But why wouldn't it
 >   have already found the global match?  Hmm.)  Otherwise, it sometimes
 >   does some sort of mangled name lookup.

the hppa stuff (i think, if my memory is not failing me) relates to the
SOM stuff that is HP's proprietary format. Maybe look in somread.c.

 > * Next, it looks in all the psymtabs.  If it finds a match, it
 >   converts the psymtab to a symtab, and returns the corresponding
 >   symbol there.
 > * Next, it looks in the static symbols for all of the symtabs.  (To
 >   what extent does this overlap with the lookup_minimal_symbol stuff
 >   earlier?)
 > * Then, it looks in the static symbols for all the psymtabs.
 > * And finally, #ifdef HPUXHPPA, it does the minimal symbol stuff that
 >   it otherwise did earlier.
 > 
 > This raises some issues:
 > 
 > * Do we _really_ want to search static symbols?  My guess is that the
 >   answer is 'yes', but it's not entirely clear to me that that's the
 >   case.  Certainly whenever we do a search that returns results that
 >   aren't strictly in line with what the language says, I get nervous.
 > 
 > * Even the simplest case of searching all the global blocks isn't
 >   implemented very well: surely we need some sort of fast lookup
 >   structure that won't require us to look at every single symtab.
 >   Assuming that we have some sort of expandable data structure in
 >   which lookups are fast, then exactly how should this work?  Should
 >   we keep replace the current global blocks by one big global table,
 >   should we have a global table that duplicates the information in the
 >   global blocks (so struct symbols corresponding to global symbols
 >   would be stored in two separate places), or should we have a global
 >   table that quickly maps names to symtabs, but have the actual
 >   symbols only stored in the global blocks of symtabs?  I'm currently
 >   leaning towards the second solution, with the possible longer-term
 >   goal of migrating towards the first solution, but it's not clear to
 >   me exactly what the consequences of these choices are.
 > 

I thought we were trying to make gdb footprint a bit smaller. So I
would be against duplicating information. But maybe I am not
understanding your proposal.


 > * Which of the structs symbol, partial_symbol, and minimal_symbol can
 >   be unified?  I tend to think that partial_symbols should go away, to
 >   be replaced by special 'incomplete' sorts of struct symbols combined
 >   with code in lookup_symbol (or wherever) that says that, if you run
 >   into one of those kinds of incomplete symbols, read in the entire
 >   symbol table for that file and flesh out all of its partial symbols.
 >   (This could open a door to a general notion of incomplete symbols
 >   that could, depending on the debugging format, be completed in a
 >   more efficient manner than the current psymtab->symtab mechanisms.)
 >   I was hoping that minimal_symbols could also be turned into special
 >   kinds of symbols, but now I'm more dubious about that; if they have
 >   to remain separate, I should presumably tweak dictionaries to let
 >   them index any sort of struct general_symbol_info, and change the
 >   minimal symbol table in ways that correspond to the changes to the
 >   global symbol table.
 > 

We could eliminate partial stabs for dwarf2, (I think that was the
plan) but I am not sure you want to do that for other symbol readers.


 > * So just what's going on with the usage of minimal symbols in
 >   lookup_symbol?  Are there any situations where looking in the
 >   minimal symbol is actually helpful?  If so, do those only have to do
 >   with ickiness related to mangled names, or is there a more serious
 >   issue that I'm missing?
 > 

debugging something compiled w/o -g. 
Assembly only debugging can also be very tricky.


 > * One issue that I didn't comment on above is that lookup_symbol has a
 >   'symtab' argument that stores the symtab in which the symbol is
 >   found.  If we have to support that, that obviously affects the data
 >   structures involved.  But it seems to me that we _don't_ have to
 >   support that: I did a cursory look through GDB's sources and, as far
 >   as I can tell, that argument is only used by linespec.c's
 >   decode_line_1.  So it seems to me that we should remove that
 >   argument from lookup_symbol and provide some sort of alternate
 >   functionality to satisfy decode_line_1's needs.
 > 

Oh our favorite function. not. in theory maybe, but tweaking with
decode_line_1 has always provided quite unexpected interesting
consequences.  (Almost as unpredictable as changing wfi). The
default_* parameters allow some commands to work w/o arguments, like
you can say 'break' and gdb knows to put a bp at the current line.  I
am not sure what you could do here, the parameter seems to be used
mostly by breakpoint code.

Elena


 > David Carlton
 > carlton@math.stanford.edu