Re: libbfd question...

[Hans-Bernhard Broeker <broeker at physik dot rwth-aachen dot de>]

On 28 May 2000, Ian Lance Taylor wrote:

>    Also, given a set of minisymbols, is there a better way to find a
>    particular address or symbol name in the table than just running through,
>    converting each to a symbol, then comparing?  Hopefully, something
>    nonlinear?  (I know I can use symbol tables (non-mini) for better
>    performance...)
> 
> No, there isn't.

Well, I have seen some code for doing this kind of lookup, mainly
introduced for the benefit of 'gprof'. I even added some code like that of
my own making to my version at home, too. It only gains something for a
certain access pattern, and it's only implemented for a few types of
symbol table, but in the cases I needed it for, it speeds up 'gprof -l' by
about an order of magnitude or more.

That code is inserted into the implementation(s) of the
*_find_nearest_line() entrypoint of the BFD for some targets. There
appears to be no sorting of the symbol table ever done by BFD itself, i.e.
it has to be traversed in the order of appearance in the file.

As it was meant for 'gprof -l', mainly, which wants to walk the debugging
symbols in order of increasing addresses, the trick used is to cache the
intermediate variables found with the current result for the next call.
It's based on the assumption that the next chunk of machine instructions
is (somewhat) likely to come fromt he same source line as the current one,
or the immediately following one. To account for some jitter in optimized
compilations, additional cache points are introduced at the start of a new
function and the start of a new source file, in the executable.

Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.