[PATCH 3/3] bfd: Improve lookup of file / line information for errors

[Andrew Burgess]

* Nick Clifton <nickc@redhat.com> [2017-02-14 09:10:08 +0000]:

> Hi Andrew,
> 
> > @@ -4155,6 +4155,38 @@ _bfd_dwarf2_find_nearest_line (bfd *abfd,
> 
> The find_nearest_line functions are used not only when emitting error/warning
> messages, but also when displaying disassembly mixed with source code.  Hence
> it is helpful if these functions can be relatively efficient.  (I have fixed
> several PRs over the last year about "objdump -dS" being very slow...)  With
> that in mind then:
> 
> 
> > +	  for (tmp = symbols; (*tmp) != NULL; ++tmp)
> > +	    if ((*tmp)->the_bfd == abfd
> > +		&& (*tmp)->section == section
> > +		&& (*tmp)->value == offset
> > +		&& ((*tmp)->flags & BSF_SECTION_SYM) == 0)
> 
> Wouldn't a binary search be more efficient here ?  Also it might be worthwhile
> caching the result in case the next call is for the same offset, or a very similar
> one.

The line immediately before the loop:

    if ((section->flags & SEC_CODE) == 0)

means that 'objdump -dS' will not be slowed down, however, I see your
point, 'objdump -DS' would be slowed down.

If I wanted to add a binary search we'd need the symbols sorted.  I
don't think that we can rely on the symbols being sorted when we enter
_bfd_dwarf2_find_nearest_line can we?  In the objdump/disassemble case
the symbols come (for elf) from elf_slurp_symbol_table, which, I don't
think guarantees ordering.

Caching the last match might help I guess, in the disassembly case
where the offset is constantly changing we could resume searching from
the last match, wrapping round at the end of the symbol list and
stopping when we get back to our start point.  This would speed things
up if we assume that symbols are usually sorted (sounds likely).

My question then would be, do you agree that the incoming symbols are
unsorted, and do you think I should create a sorted copy in the cached
data, and so allow for a binary search?

I appreciate your advice,

Thanks,
Andrew