[PATCH] Fix return code in _bfd_dwarf2_find_nearest_line().

[Steinar H. Gunderson]

On Wed, Mar 23, 2022 at 12:10:00PM +0000, Nick Clifton wrote:
> So the proper way to solve this problem is to create a new function, or
> rather group of functions.  One to register a symbol table and then another
> the perform scans using that symbol table.  And another function to free
> any stored data, of course.
> 
> Then callers can choose which API to use.  Fortunately (or maybe
> unfortunately) the BFD library has a history of having an unstable API,
> so you do not have to worry about versioning.

Well, I guess since they're also undocumented, and the symbol arrays
usually are provided by bfd, we could claim that this was an expectation
all along... :-) (Or we could track which ones come from bfd, and store
their associated persistent structures. The user isn't supposed to
modify them, I would suppose.)

The right thing to do is probably registration, but I don't think I'm
going down that path. With the patches posted so far (the two that have
been alreayd applied, and the trie for address-to-CU mapping), it's
already fast enough for my use case; an extra 40% would of course always
be nice to have, but not really a game-changer.

/* Steinar */