[PATCH] Fix return code in _bfd_dwarf2_find_nearest_line().

[Nick Clifton]

Hi Steinar,

> I looked into trying to making a faster structure, probably reusing the
> trie from the other patch I posted (ie., making a separate trie that
> maps address-to-symbol instead addition-to-compilation-unit), but it
> seems the API is that the client has to send in the list of symbols it
> wants to use for fallback?

I do not think that it is for fallback, but rather that it is expected
that all callers of this function will have already decided upon the symbol
table that they want to use, and so it is provided as a parameter.  (A
single binary file can have multiple symbol tables, so there needs to be
some way to select which one to use.  Making the caller perform this choice
is the easiest solution).

  Is that right; so we cannot really create a
> persistent structure? (The find_nearest_line function is marked as not
> documented yet, so it's not all that easy to know what the intended API
> is :-) )


You probably could make a persistent structure.  It is unlikely that the
code will called with different symbol tables under most use cases.  But
you would need to detect if this has happened and ditch/refresh your
storage in that case.

Cheers
   Nick