Re: symbol table lookup performance

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Daniel" == Daniel Berlin <dan@cgsoftware.com> writes:
Daniel> Also, what type of debug info is this on?  It makes a huge
Daniel> difference.

This case is on an a.out/stabs target.  We also have ELF/stabs targets.
I have not had the time to investigate converting our ELF targets from 
stabs to DWARF2

Daniel> If it's not too much trouble, could you tell me if
Daniel> lookup_partial_symbol is trying to look up the same 100 or so
Daniel> symbols, again and again?  

No problem at all.  Yes, lookup_symbol() (thus lookup_partial_symbol)
is trying to look up the same symbols again and again.

Daniel> I would imagine at a given point in time, their is a set of
Daniel> symbols you'll be using.  If it's trying to look up the same
Daniel> symbols, again and again, i'll implement a simple LRU cache
Daniel> for the past 100 looked up symbols.

I think a cache is unlikely to help in this case.  Although GDB tries
to look up the same symbols again and again, in most cases the search
is unsuccessful because the symbols simply aren't in the symbol table.
A "negative" cache, one that indicates that a symbol isn't present,
would be useful but might not be the right way to solve this problem.

You might ask why is a script causing GDB to look up symbols that
aren't in the object?  In my case, it is caused by the script
referencing structure and union fields.

        while $do_loop == 1
            if ($curHdrp.pPrevHdr != $prevHdrp)
                set $do_loop = 0
            end
            if ($curHdrp.free == 1)
                set $do_loop = 0
            end
            .
            .
            .
        end

In the above example, both "pPrevHdr" and "free" are looked up in the
symbol table.  "pPrevHdr" is not a symbol in the image and the search
fails; "free" just happens to be a symbol and the search succeeds.  In
both cases, it does not matter that much, because the "exp : exp '.' name" 
rule in the yacc grammar doesn't look at the symbol values, it writes a
string containing the field name to be interpreted later.

I've only scratched the surface of the expression parser, but it seems
that name to symbol happen at too low of a level.

        --jtc

-- 
J.T. Conklin
RedBack Networks